ikanow / infinit.e Goto Github PK

Since that DB node might have spawned a transient arbiter during startup, which then doesn't always get deleted.

When the "config DB" script (arbiter manager) then tries to spawn the permanent arbiter, it silently fails because one is already present

The simple workaround is to not use DB nodes for config DBs in any non trivial cluster.

Did anyone try download and run successful the community demo version (Infinit.e_VM_demo.ova)?

The issue appears to be that MongoInputFormat doesn't work on large datasets (too many mappers generated?), whereas InfiniteMongoInputFormat does (but backs off to MongoInputFormat if there are >8*12.5K documents).

The short term fix will be to force plugins to use InfiniteMongoInputFormat if in local mode, even if larger than the current limit (it's not like performance is going to be amazing in local mode anyway)

The workaround (from August OSS release) is to set "$splits" and "$docsPerSplit" (defaulting to 8 and 12500, see above) in the query object so that when multiplied they are larger than the number of documents to be processed.

This issue is recorded internally as INF-2018

While setting upi the development environment, as mentioned at https://ikanow.jira.com/wiki/display/INFOSS/Infinit.e+-+developing+core+infrastructure project title is different in repository than mentioned in tutorial, also there is no src folder present in those folders.

See #1

List of offending directories (" find . -type d -empty"):
core/infinit.e.processing.custom.library/lib (confirmed)

/visualization/widgets/flex/InfiniteEntityGroupWidget/build (unconfirmed - this is a unfinished development widget anyway, probably should just get removed from the github tree)

The other instances appear harmless

The mongodb cannot start and seem like error is not clear the root cause.

2016-03-10T17:32:49.229+0800 [mongosMain] warning: Failed to connect to 127.0.0.1:27016, reason: errno:13 Permission denied
2016-03-10T17:32:49.230+0800 [mongosMain] ERROR: error upgrading config database to v5 :: caused by :: could not load config version for
upgrade :: caused by :: connection pool: connect failed 127.0.0.1:27016 : couldn't connect to server 127.0.0.1:27016 (127.0.0.1), connect
ion attempt failed

I am running CENTOS 7 on vmware.

See title

Due to a conflict with elasticsearch 1.0

(ERROR: "Configuration/Installation error: org.tartarus.snowball.ext.englishStemmer.eq_s(ILjava/lang/String;)Z")

To fix simply upgrade to the latest OSS release (patched version of May), eg

yum upgrade infinit.e-processing-engine infinit.e-interface-engine

As of Sep 2014 release, running simple numerical calculations with _memoryOptimization = true resulted in NaN deserialization errors. This should probably be avoided until fixed

(https://ikanow.jira.com/wiki/display/INFAPI/Javascript+Engine+for+Plugin+Manager)

these two classes should be replaced
see here for some ideas
http://www.asgarli.net/2011/03/replacing-sunmiscbase64encoder-and.html
this is on hold until the build works 100%

Infinit.e/core/infinit.e.data_model/src/com/ikanow/infinit/e/data_model/store/config/source/SourcePojo.java:29: warning: sun.misc.BASE64Encoder is internal proprietary API and may be removed in a future release
    [javac] import sun.misc.BASE64Encoder;
    [javac]                ^
    [javac] Infinit.e/core/infinit.e.data_model/src/com/ikanow/infinit/e/data_model/store/config/source/SourcePojo.java:467: warning: sun.misc.BASE64Encoder is internal proprietary API and may be removed in a future release
    [javac]         shah256Hash = (new BASE64Encoder()).encode(md.digest());    
    [javac]                            ^
    [javac] 2 warnings

(we list top-level directories recursively, which makes this even worse)

Issue INF-2131 on JIRA