Akka Router with multiple actors not receiving messages properly - grails

Here i created a router with SmallestMailboxRouter
ActorRef actorRouter = this?.getContext()?.actorOf(new Props(RuleStandardActor.class).withRouter(new SmallestMailboxRouter(38)),"standardActorRouter")
Now in for loop i created 38 actors
for(int i=0;i <38;i++) {
ruleStandardActorRouter?.tell(new StandardActorMessage(standard: standard, responseVO: responseVO, report: report), getSelf());
}
each actor will process the logic and returns the score and message . i am receiving the message by overriding onreceive method and adding them to a list
If i run the program multiple times i am getting different scores. but it should return always same score as i am giving same input.
if (message instanceof StandardActorResponse) {
StandardActorResponse standardActorResponse = message
standardActorResponseList?.add(standardActorResponse)
}
here standardActorResponse contains message and score . if i am using same logic by just using for loop instead of akka framework i am reciving conisstant result. but in akka randomly getting different results. for example i have some rules like loginexistence and navigationexistence and alertsexistence rules. i have given one html source to these rules to check whether the html source have login,alerts,navigation links in that source. some times i am getting login doesnt exists, some times navigation doesnt exist, some times alerts doesnt exists by using akka routers and actors. but if i use for loop i am always getting same result
can any one help me to find the problem. i am using akka 2.1.4

Probably the for loop is already finished before the mailbox size is recognised. Try adding a sleep in the for loop to see the results.

Related

New Relic alert when application stop

I have an application deployed on PCF and have a new relic service binded to it. In new relic I want to get an alert when my application is stopped . I don't know whether it is possible or not. If it is possible can someone tell me how?
Edit: I don't have access to New Relic Infrastructure
Although an 'app not reporting' alert condition is not built into New Relic Alerts, it's possible to rig one using NRQL alerts. Here are the steps:
Go to New Relic Alerts and begin creating a NRQL alert condition:
NRQL alert conditions
Query your app with:
SELECT count(*) FROM Transaction WHERE appName = 'foo'
Set your threshold to :
Static
sum of query results is below x
at least once in y minutes
The query runs once per minute. If the app stops reporting then count will turn the null values into 0 and then we sum them. When the number goes below whatever your threshold is then you get a notification. I recommend using the preview graph to determine how low you want your transactions to get before receiving a notification. Here's some good information:
Relic Solution: NRQL alerting with “sum of the query results”
Basically you need to create a NewRelic Alert with conditions that check if application available, Specially you can use Host not reporting alert condition
The Host not reporting event triggers when data from the Infrastructure agent does not reach the New Relic collector within the time frame you specify.
You could do something like this:
// ...
aggregation_method = "cadence" // Use cadence for process monitoring otherwise it might not alert
// ...
nrql {
// Limitation: only works for processes with ONE instance; otherwise use just uniqueCount() and set a LoS (loss of signal)
query = "SELECT filter(uniqueCount(hostname), WHERE processDisplayName LIKE 'cdpmgr') OR -1 FROM ProcessSample WHERE GENERIC_CONDITIONS FACET hostname, entityGuid as 'entity.guid'"
}
critical {
operator = "below"
threshold = 0
threshold_duration = 5*60
threshold_occurrences = "ALL"
}
Previous solution - turned out it is not that robust:
// ...
critical {
operator = "below"
threshold = 0.0001
threshold_duration = 600
threshold_occurrences = "ALL"
}
nrql {
query = "SELECT percentage(uniqueCount(entityAndPid), WHERE commandLine LIKE 'yourExecutable.exe') FROM ProcessSample FACET hostname"
}
This will calculate the fraction your process has against all other processes.
If the process is not running the percentage will turn to 0. If you have a system running a vast amount of processes it could fall below 0.0001 but this is very unprobable.
The advantage here is that you can still have an active alert even if the process slips out of your current time alert window after it stopped. Like this you prevent the alert from auto-recovering (compared to just filtering with WHERE).

Specman - Monitor doesn't recognize events which it is supposed to provide

According the Universal Verification Methodology (UVM) e User Guide of Cadence:
The events recognized by the monitor depend on the actual protocol. Typically, for the basic data item the monitor
provides an item_started and an item_ended event (for example, packet_started and packet_ended). The monitor collects
the item data from the signals and creates a current_item that has the complete item data, ready to be used when the
item_ended event occurs. In addition to the raw data, the monitor should collect relevant timing information such as the
duration of the transaction.
I try to execute the following in my agent by:
connect_ports() is also {
uart_monitor.uart_frame_s_started.connect(tx_scb.uart_frame_s_add);
uart_monitor.uart_frame_s_ended.connect(tx_scb.uart_frame_s_match);
};
I get the following errors: Error: 'uart_monitor' (of 'uart_tx_monitor_u') does not have 'uart_frame_S_started'field.... Error: 'uart_monitor' (of 'uart_tx_monitor_u') does not have 'uart_frame_S_ended'field
But when I declare the events in the monitor by:
event uart_frame_s_started;
event uart_frame_s_ended;
There are no errors.
Why should I declare those events if they are supposed to be provided by the monitor?
are you using the uvm scoreboard? if so, its ports (add and match) are TLM ports. meaning - they expect to get data item written to them.
but you connect to them event ports.
there is something strange - in your code, the events names have a lower 's', but in the error - as you print it - there is capital S. is it uart_frame_s_started or uart_frame_S_started ?

"EntityNotFoundException: Unable to load RELATIONSHIP with id" when saving RelationshipEntity (with huge generated cypher query)

I am using spring-data-neo4j 4.2.0.M1 and neo4j-ogm 2.0.4 with neo4j 3.1.0-M04.
The application is generally working, except for one case where I try to save a collection of modified RelationshipEntities.
The code is sth. like this:
List<Relationship> updatedRelationships = new ArrayList<>();
for(Relationship relationship : modifiedRelationships)
{
relationship = relationshipRepository.load(relationship);
relationship.setValue("value");
updatedRelationships.add(relationship);
}
relationshipRepository.save(relationships);
The RelationshipEntity is annotated with #RelationshipEntity and has a few properties in addition to the #StartNode and #EndNode. Only the property mentioned above is changed though. The RelationshipEntity is loaded inside the loop because I previously noticed lost information (namely value of other properties) when executing this.
Note that the above mentioned code is executes for many RelationshipEntities in succession. Each relationship (probably) occurs only once, but start and end nodes probably occur several times. To my knowledge, no relationship is deleted though.
The exception I get is:
Caused by: org.neo4j.kernel.api.exceptions.EntityNotFoundException: Unable to load RELATIONSHIP with id 20683203.
at org.neo4j.kernel.impl.api.store.DiskLayer.relationshipVisit(DiskLayer.java:432)
at org.neo4j.kernel.impl.api.store.CacheLayer.relationshipVisit(CacheLayer.java:326)
at org.neo4j.kernel.impl.api.StateHandlingStatementOperations.relationshipVisit(StateHandlingStatementOperations.java:1409)
at org.neo4j.kernel.impl.api.ConstraintEnforcingEntityOperations.relationshipVisit(ConstraintEnforcingEntityOperations.java:416)
at org.neo4j.kernel.impl.api.OperationsFacade.relationshipVisit(OperationsFacade.java:493)
at org.neo4j.kernel.impl.factory.GraphDatabaseFacade.getRelationshipById(GraphDatabaseFacade.java:300)
... 104 common frames omitted
The query that is executed before (which is probably the "save" query) is huge and exceed the character limit here (sth. like 200k characters). Apparently the query touches where more relationships than necessary (from business logic point-of-view) since only about 30 entities are actually saved. I would assume that the resulting query (or queries if updates are done per entity) are rather brief.
2016-08-28 20:16:33,007 I [pool-4-thread-1 ] (EmbeddedRequest.java:155) Request: START r=rel({relIds}) FOREACH (row in filter(row in {rows} where row.relId = id(r)) | SET r += row.props) RETURN ID(r) as ref, ID(r) as id, {type} as type with params {relIds=[13744338, 19099951, 12570789, 12570785, 13744377, 13648126, 12570765, 20627727, 13744356, 20627724, 12570760, 19263773, 19257628, 20113678, 19099932, 19259756, 18796874, 13783174, 19097972, 19083644, 19099970, 19097921, 19077446, 19263810, 13744312, 20568405, 20904270, 19097937, 12570827, 20627779, 20648258, 12570816, 20683195, 19259812, 20683194, 20683193, 20683192, 19083690, 20683186, 20683191, 19259819, 18819471, 20683178, 20683177, 12570669, 20683176, 19276210, 19933607, 20683171, 18844038, 19100089, 20683174, 20683173, 20683163, 20683162, 20683161, 13744242, 19257729, 12570649, 20683165, 20683164, 19087754, 21703141, 12570641, 8341711, 19259796, 8704051, 19915155, 19261851, 13783062, 13783063, 19091955, 18182597, 19276276, 19276275, 20623852, 20607468, 20623853, 19100155, 19233277, 13783048, 19261946, 12570719, 21789101, 12570718, 19075526, 19259842, 19257807, 12570707, 13715516, 19098061, 19261908, 20683208, 20683215, 19100118, 20683212, 20683203, 19276254, 20683201, 20683207, 19091934, 20683206, 19261915, 19097639, 19101736, 19101749, 18821129, 19097659, 19124284, 13662709, 13744628, 19052549, 19089427, 13744612, 19265563, 19251300, 19089509, 19251298, 20631665, 19251305, 19265642, 13744513, 19261558, 19261511, 19265606, 19081291, 18903113, 18903114, 19251273, 8341775, 12597685, 13744548, 19081308, 18725021, 18725020, 19273892, 19099808, 19089572, 19097772, 13744449, 13683011, 18178177, 19273905, 19093694, 18178231, 19124358, 20633756, 13744502, 19081356, 18651311, 19093661, 20562171, 19263725, 20625639, 19099901, 20631774, 20676819, 18651383, 20676822, 20676821, 20676820, 19097811, 19099862, 13744428, 20631751, 18178280, 18668312, 19100453, 19088171, 20708148, 19143487, 19088184, 19094334, 18668349, 13744883, 19145485, 20607750, 19094301, 19086108, 13744792, 20611958, 19143528, 13662849, 13744829, 12571346, 20611918, 20611919, 18811753, 19100506, 13744813, 19084195, 13662806, 20708275, 19098546, 20612001, 13744752, 20708253, 12595823, 20611976, 19147673, 19258343, 19274725, 19084262, 19082212, 19096548, 20591606, 19086317, 13662720, 8348332, 19274738, 8348329, 19096571, 21703569, 19440630, 13744654, 21824427, 13744701, 19258320, 20612032, 19086296, 19080158, 19282466, 19145249, 19261996, 20607539, 12596170, 19282472, 18776588, 19100208, 12596183, 18182658, 19233341, 19278395, 19096126, 19098115, 20640284, 18844217, 19255810, 19259919, 19257864, 20623892, 19091980, 19933697, 19282450, 19100180, 19261981, 12596219, 12596113, 19255924, 20707949, 12596118, 19098228, 18704970, 12596122, 19278458, 19096190, 19278456, 19253826, 19278412, 13745087, 19100241, 13745066, 18704995, 19278500, 13744981, 5954519, 19094199, 19143356, 13744970, 12598116, 18840242, 13745006, 18676445, 18008789, 19096298, 18676426, 20607724, 13744906, 13755199, 19094227, 12596419, 19098918, 19256621, 19090736, 21075287, 19100929, 21851496, 20876568, 13681912, 12596463, 12596465, 19090704, 10951825, 12596471, 13681897, 13753581, 19094814, 12596352, 21703948, 21695756, 18699605, 19256693, 18818378, 12596376, 19090755, 19256647, 13681844, 19082583, 18836839, 18699621, 12596409, 20618681, 21544395, 19916202, 12596299, 12596310, 19436940, 19099014, 19094918, 19916170, 13681782, 12596335, 20680073, 13681762, 13681763, 19099028, 19094938, 21081473, 13681682, 20680177, 12596242, 19099126, 19500540, 21081496, 10492993, 19099087, 21081517, 19099094, 21704112, 19098665, 18680849, 12596685, 12596689, 19274804, 20648995, 19137597, 21048411, 19088387, 19262470, 20657183, 19086357, 19258397, 18680869, 12596731, 19088413, 19272807, 19274848, 19272811, 12596622, 18811984, 15797667, 19096694, 19082357, 19262579, 19274875, 19137604, 12596642, 19274830, 19098696, 13682107, 12596651, 19096655, 20632650, 19088474, 19274845, 19262555, 19100834, 13682007, 19098794, 19100851, 12596565, 20556972, 19254450, 20597926, 12598622, 20597925, 20649114, 19100800, 13682036, 19100806, 12596582, 18703539, 20638856, 20598010, 18703582, 19094763, 19100905, 19096808, 20634857, 20597991, 5877179, 5877178, 20597977, 5877181, 19098822, 12596527, 12596532, 19199781, 19265313, 19261228, 20625200, 19257134, 20625201, 18714376, 19085108, 19253054, 19253048, 19265339, 20637459, 20637456, 19085074, 21081974, 8316482, 20598534, 18714402, 19107685, 19253090, 20615029, 19097462, 19263346, 20621152, 19263352, 19259207, 13729470, 19085140, 20688830, 19251116, 19259304, 13678173, 20615087, 12596830, 19097474, 21082087, 12596840, 19263368, 19251093, 8701488, 19267475, 8349384, 12572165, 8349360, 12596751, 19077119, 12596765, 20625380, 19077057, 19089350, 21825447, 21702567, 13682208, 12596785, 8316559, 18178020, 19253207, 20688847, 12596788, 19267536, 20688838, 12570558, 19232295, 12570550, 13783001, 20643352, 20694547, 19095051, 20643338, 19232272, 12570505, 20641280, 20694529, 20641284, 19099164, 20821624, 20821626, 20631165, 20821619, 12570606, 19439229, 12570601, 18820674, 19232327, 12570588, 20694621, 20641362, 20119134, 20631115, 20680264, 20618831, 19093080, 18824862, 19256994, 7325670, 20821668, 19257017, 13782863, 16494427, 20620952, 19256967, 20637331, 18030271, 8267731, 19256977, 20670095, 19099360, 20637433, 19261170, 19265276, 20907749, 18822910, 20621021, 19099339, 19252938, 19936961, 19099345, 19109599, 19257048], rows=[omitted]
I've tried to load the relationship with that id directly, but none exists. The same code executes fine for other RelationshipEntities but repeatedly fails for either this or one of a handful other ones.
Any ideas as to what could cause this or how this can be better debugged?
I think I somehow solved this with the following steps:
Replaced saving the RelationshipEntity with saving the modified NodeEntity
Making such modifying operations sequential (previously this could happen in parallel)
Encapsulate the modifying operation in a transaction
Fixed a bug where in the same transaction the same entity was saved twice (without changing again in the meantime)
Fetching the entity again at the beginning of the transaction in order to have the latest state available
Since I was prettty much in the dark about this topic until it finally worked, I am not sure if all of the steps actually helped solving this. It may actually have been only a subset.
What I can see though now is, that the huge update queries are now smaller (albeit still quite big) but actually seem to contain "real" updates instead of mostly "null" properties. I assume that previously it didn't really contain an update and was instead overriding properties with "null". The fact that this is now working is probably related to the fact, that the entity is now updated before beginning to modify it and that no other modifying operation can run in parallel.
I had the same problem. For me it was simply the neo4j-ogm-embedded-driver
version I had to include in my pom. The one I defined overwrote the one
defined in spring-data-neo4j.
If you only save the relationshipEntity,you could only using next snippet:
List<Relationship> updatedRelationships = new ArrayList<>();
for(Relationship relationship : modifiedRelationships)
{
relationship = relationshipRepository.load(relationship);
relationship.setValue("value");
updatedRelationships.add(relationship);
}
relationshipRepository.save(updatedRelationships,0);
it would save the related properties on relationshipEntity and meanwhile ignore any related entities.

How can I track the current number of viewers of an item?

I have an iPhone app, where I want to show how many people are currently viewing an item as such:
I'm doing that by running this transaction when people enter a view (Rubymotion code below, but functions exactly like the Firebase iOS SDK):
listing_reference[:listings][self.id][:viewing_amount].transaction do |data|
data.value = data.value.to_i + 1
FTransactionResult.successWithValue(data)
end
And when they exit the view:
listing_reference[:listings][self.id][:viewing_amount].transaction do |data|
data.value = data.value.to_i + -
FTransactionResult.successWithValue(data)
end
It works fine most of the time, but sometimes things go wrong. The app crashes, people loose connectivity or similar things.
I've been looking at "onDisconnect" to solve this - https://firebase.google.com/docs/reference/ios/firebasedatabase/interface_f_i_r_database_reference#method-detail - but from what I can see, there's no "inDisconnectRunTransaction".
How can I make sure that the viewing amount on the listing gets decremented no matter what?
A Firebase Database transaction runs as a compare-and-set operation: given the current value of a node, your code specifies the new value. This requires at least one round-trip between the client and server, which means that it is inherently unsuitable for onDisconnect() operations.
The onDisconnect() handler is instead a simple set() operation: you specify when you attach the handler, what write operation you want to happen when the servers detects that the client has disconnected (either cleanly or as in your problem case involuntarily).
The solution is (as is often the case with NoSQL databases) to use a data model that deals with the situation gracefully. In your case it seems most natural to not store the count of viewers, but instead the uid of each viewer:
itemViewers
$itemId
uid_1: true
uid_2: true
uid_3: true
Now you can get the number of viewers with a simple value listener:
ref.child('itemViewers').child(itemId).on('value', function(snapshot) {
console.log(snapshot.numChildren());
});
And use the following onDisconnect() to clean up:
ref.child('itemViewers').child(itemId).child(authData.uid).remove();
Both code snippets are in JavaScript syntax, because I only noticed you're using Swift after typing them.

Faster reading of inbox in Java

I'd like to get a list of everyone who's ever been included on any message in my inbox. Right now I can use the javax mail API to connect via IMAP and download the messages:
Folder folder = imapSslStore.getFolder("[Gmail]/All Mail");
folder.open(Folder.READ_ONLY);
Message[] messages = folder.getMessages();
for(int i = 0; i < messages.length; i++) {
// This causes the message to be lazily loaded and is slow
String[] from = messages[i].getFrom();
}
The line messages[i].getFrom() is slower than I'd like because is causes the message to be lazily loaded. Is there anything I can do to speed this up? E.g. is there some kind of bulk loading I can do instead of loading the messages one-by-one? Does this load the whole message and is there something I can do to only load the to/from/cc fields or headers instead? Would POP be any faster than IMAP?
You want to add the following before the for loop
FetchProfile fetchProfile = new FetchProfile();
fetchProfile.add(FetchProfile.Item.ENVELOPE);
folder.fetch(messages, fetchProfile);
This will prefetch the "envelope" for all the messages, which includes the from/to/subject/cc fields.
You can use fetch-method in Folder. According Javadocs:
Clients use this method to indicate that the specified items are
needed en-masse for the given message range. Implementations are
expected to retrieve these items for the given message range in a
efficient manner. Note that this method is just a hint to the
implementation to prefetch the desired items.
For fetching FROM appropriate FetchProfile is ENVELOPE. Of course it is still up to implementation and mail server does that really help.

Resources