I am migrating a spring state machine working code to version 3.0.0 to get benefit of reactive implementation and when I call to
stateMachinePersister.restore(stateMachine, buildKey(id))
I get the error
Error restoring statemachine; block()/blockFirst()/blockLast() are blocking, which is not supported in thread reactor-http-epoll-3
Looking in AbstractStateMachinePersister code I can see the call to block() method so how can I achieve to restore the state machine?
Edit: This happens completely aleatory, for the same request sometimes fails and sometimes work
Found this issue on github project https://github.com/spring-projects/spring-statemachine/issues/949
We will have to wait for future versions, not mature enough.
Solved on Jul 27th: github.com/spring-projects/spring-statemachine/commit/…. You can use the new method resetStateMachineReactively from version 3.0.x
Related
I found 2 options how to add classes to hazelcast:
CodeDeployment
clientUserCodeDeploymentConfig.addClass(cz.my.DemoTask.class);
problem is when I change code in this task I got exception:
java.lang.IllegalStateException: Class com.model.myclass is already in a local cache and conflicting byte code representation
Use some serialization like IdentifiedDataSerializable or Portable and add jar to client and server hazelcast with configuration.
so even this is versioned when you need to change our Task you need to update jar and restart server
so is there some other options ?
I found similar issue which is almost 2 years old where is mention:
For the functional objects, we don't have a solution in place but it
is on the road map.
so I am curious if there is some update about this.
We have an "cache" (javax.cache.Cache) implementation that is a wrapper of Hazelcast's IMap. We use a composite Object key.
We upgraded from version 3.12.5 to 5.1.1. When I deploy the system on a local Windows machine, all works well. But when I deploy the system into an Kubernetes environment, the map just "does not work". Values do not get persisted into the map (after a put operation). An Hazelcast cluster does get formed so it does not seem to be an auto discovery issue. I also have another K8S env in which it does work properly.
I enabled Hazelcast's diagnostic mode and it does not seem to show me anything useful. I do not get any error or warn messages from the com.hazelcast.* package. The same issue happened also when I tried version 4.x.
I am trying to explore ways which will help to the realise what is the issue here. Thank you.
Turns out it is a bug. Hazelcast recommends to use the value of 0 instead.
I had the same problem but i was migrating from hazelcast 3.11.1 to 5.1.2, I found the IMap in "com.hazelcast.map" not in "com.hazelcast.core"
I'm trying to reproduce data from InvisiSpec paper. InvisiSpec is a defense mechanism in hardware for Spectre attack. I'm using github code that was released by the author of the paper.
Currently I can build and run last version of gem5 simulator on my system successfully. However I get the following exception when trying to build their code
Exception: MI_example-cache.sm:401: Error: Invalid method call: Type 'Sequencer' does not have a method evictionCallback, 'evictionCallback_Addr' nor '':
I don't know where this error comes from. I looked through many things but haven't had any success. I appreciate if anyone could help me find what is causing the exception. The issue is posted in the corresponding github repository too.
The above error and some other errors that came after were related to protocol MI and also scons and python version. I could build it with MESI protocol.
python2.7 `which scons` build/X86/gem5.opt --default=X86 PROTOCOL=MESI_Two_Level
Comparing the modified version of InvisiSpec with original Gem5, I believe the author of paper made changes for memory consistency that works with MESI protocol. Codes related to other protocols need to be updated accordingly.
i have to do a reptitive task in nodeJS and i've seen there is existing package like this one.
https://www.npmjs.com/package/node-cron
and the actual platform where i'm hosted propose inside cronjob.
https://www.netlify.com/docs/webhooks/
so my question is when it's more interessant to use the platform or a package.
thanks.
From the URL posted i didn't see any method of setting up a cron job using webhooks. Unless you were thinking of setting up a webhook that listens for a post which is sent using a linux cron job or the like?
Regardless, the actual question about using a platform or a package. They have pros and cons, but based purely on your question I would go with the platform.
If you choose to use a package you will have to write the code to call the package (which you need to test, maintain and run). You need to ensure that the node process is always up and running, if it dies or exits that it is re-spawned, that if the operating system reboots the node process gets kicked off again. All these problems are can be easily solved (PM2 for instance) but the fact is you need to think of the problems and solve them yourself or the cron job might not run when you want it to.
When using the platform you know that it is well tested, that it will work as documented, and that it will be resilient to failure modes that you might not be aware of.
I'm receiving SIGSEGV quite randomly when running an express app with PM2. The strange thing is the server runs quite well for the past few weeks. It does not print any error message except:
App [XXX] with id [7] and pid [27757], exited with code [255] via signal [SIGSEGV]
After implementing the "segfault-handler" module, I started to receive some stack traces. It seems the app encounters a few different segmentation fault:
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fd211f87330]
node(_ZN2v88internal9HashTableINS0_15ObjectHashTableENS0_20ObjectHashTableShapeENS0_6HandleINS0_6ObjectEEEE18FindInsertionEntryEj+0x40)[0xc0b680]
node(_ZN2v88internal15ObjectHashTable3PutENS0_6HandleIS1_EENS2_INS0_6ObjectEEES5_i+0x124)[0xc0c0a4]
node(_ZN2v88internal7Runtime17WeakCollectionSetENS0_6HandleINS0_16JSWeakCollectionEEENS2_INS0_6ObjectEEES6_i+0x59)[0xc7d639]
node(_ZN2v88internal25Runtime_WeakCollectionSetEiPPNS0_6ObjectEPNS0_7IsolateE+0x11d)[0xc7d89d]
[0x2acdd80963b]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f0fc311c330]
node(_ZN2v88internal32IncrementalMarkingMarkingVisitor26VisitFixedArrayIncrementalEPNS0_3MapEPNS0_10HeapObjectE+0x376)[0xad8a16]
node(_ZN2v88internal18IncrementalMarking4StepElNS1_16CompletionActionENS1_18ForceMarkingActionENS1_21ForceCompletionActionE+0x2c1)[0xad6181]
node(_ZN2v88internal8NewSpace15SlowAllocateRawEiNS0_19AllocationAlignmentE+0x74)[0xb05244]
node(_ZN2v88internal4Heap11AllocateRawEiNS0_15AllocationSpaceES2_NS0_19AllocationAlignmentE+0x1b9)[0xa678c9]
node(_ZN2v88internal4Heap20AllocateFillerObjectEibNS0_15AllocationSpaceE+0x19)[0xab00b9]
node(_ZN2v88internal7Factory15NewFillerObjectEibNS0_15AllocationSpaceE+0x2d)[0xa67d1d]
node(_ZN2v88internal29Runtime_AllocateInTargetSpaceEiPPNS0_6ObjectEPNS0_7IsolateE+0x5e)[0xc99e8e]
[0x249862c06355]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fbebabd2330]
node(_ZN2v88internal9HashTableINS0_15ObjectHashTableENS0_20ObjectHashTableShapeENS0_6HandleINS0_6ObjectEEEE18FindInsertionEntryEj+0x40)[0xc0b680]
node(_ZN2v88internal15ObjectHashTable3PutENS0_6HandleIS1_EENS2_INS0_6ObjectEEES5_i+0x124)[0xc0c0a4]
node(_ZN2v88internal7Runtime17WeakCollectionSetENS0_6HandleINS0_16JSWeakCollectionEEENS2_INS0_6ObjectEEES6_i+0x59)[0xc7d639]
node(_ZN2v88internal25Runtime_WeakCollectionSetEiPPNS0_6ObjectEPNS0_7IsolateE+0x11d)[0xc7d89d]
[0x125b9620963b]
I know there is little information here. Can anyone please tell me a good way to start diagnosing? I've checked the PM2 log, mongoDB log but no luck.
Thanks!
Mars
Since the stack trace is different every time and not very illuminating, all you can do is try things. The first main suspects will be things that use native code because it's not that likely that plain Javascript is causing a segFault. It is probably native code that is somehow corrupting memory or not properly interacting with the garbage collector in node.js.
So, the things to look for are the interaction between your current version of node.js and the things you have that use native code (such as mongoDB). Here are things to try:
Identify all modules that use native code and temporarily remove any that you can live without.
Upgrade both node.js and mongoDB to recent versions in case you have some interaction between their specific versions that is causing the problem. If you can't upgrade node.js to a recent stable version, then make absolutely sure that all the modules you are running are certified to be stable with the version of node.js that you do have.
Restart your server just in case there's anything goofed up in the OS that is contributing to the problem.
Start with a clean database or run some sort of database check on your database in order to verify that there is no corruption there.
Whenever you update your DB scheme, make sure you have a strategy for moving the prior database forward (it looks like in MongoDB you can just make sure you assign a default value to new scheme elements).
Gather new info after making changes and repeat the process, trying to only change one thing at a time so that if it fixes the issue you will know exactly which item it was that fixed it.
Something like that can happen when you copy the code with node_modules that included binary modules compiled for a different architecture than the one you're trying to run it on.
Try either removing node_modules and running npm install from scratch, or you can try running npm rebuild without removing node_modules.