In hoc articulo quomodo et quare elaboravimus loquemur - ma- china quae informationes transfert inter applicationes clientium et 1C:inceptum ministrantium - ab instituendo negotium ad cogitandum per singula architecturae et exsecutionis.
Systema Interactionis (infra post SV) distributum est systema nuntiandi culpae tolerans cum partus tuto. SV designatum est ut summus onus ministerium cum scalabilitate alta, tam in promptu quam in servitio online (provisum a 1C) et sicut productum massarum productum quod explicari potest ad facilities servo tuo.
SV usus repono et quaerere engine . Etiam de Java loquemur et quomodo scandimus postgreSQL horizontaliter.
DE PECCATO quaestio
Ut pateat cur Systema Interactionis creavimus, pauca tibi dicam quomodo applicationes negotiorum in 1C operibus evolutionis.
Primum, pauca de nobis pro iis qui nondum sciunt quid agimus :) Facimus 1C:Inceptum technologiae suggestum. In suggestu negotium applicationis evolutionis instrumenti includit, sicut runtime quod permittit negotia applicationes ad currendum in ambitu transversali.
Cliens-server progressio paradigma
Negotium applicationes creatae in 1C:Inceptum agunt in tres gradus architectura "DBMS - application server - client". Applicationem scriptum in codice exsecutioni mandari potest de servo applicationis sive in clientela. Totum opus cum obiectis applicationis (directoriis, documentis, etc.), ac legendis et scribendis datorum solum in calculonis servis exercetur. Munus formarum et praecepti interfacies etiam in calculonis servi ad effectum deducitur. Cliens accipit, aperiens et ostentans formas "communicantes" cum usore (monitiones, interrogationes...), parvas calculos in formis, quae vivam responsionem requirunt (exempli gratia, multiplicando pretium quantitati), operando cum loci fasciculis; cum apparatu laborat.
In schedula codice, capita processuum et functionum explicite indicabunt ubi signum exsecutioni mandabitur - adhibitis admonitionibus &AtClient / &AtServer (&AtClient / &AtServer in versione Anglica linguarum). 1C tincidunt nunc me corrige dicendo normas esse actu sed nobis id sit amet nunc.
Servum codicem e codice clientis vocare potes, sed clientem codicem e codice servitore non potes appellare. Hanc limitationem fundamentalem fecimus multis de causis. Praesertim quod in codice servo ita scribi debet ut exsequatur eodem modo, ubicumque appellatur - a cliente vel a servo. Et in casu vocandi codicem ab alio servo codice, clientis non est talis. Et quia in exsecutione codicis, cliens qui appellabat claudere potuit, applicationis exitus, et cultor non amplius aliquem appellare debet.
Codicis qui e tesseram strepita tractat: modum procedendi a cliente vocans operabitur, vocans processum clientem a servo nolente
Hoc significat, si velimus aliquem nuntium mittere a servo ad clientem applicationis, exempli gratia, generationem famae "longi currit" perfecit et relatio spectari potest, methodum talem non habemus. Dolis utendum est, exempli gratia, servo e codice cliente periodice tondendo. Sed ac- cedit ratio cum supervacuis vocat, et plerumque non valde elegans spectat.
Et est etiam opus, verbi gratia, cum telephonica vocatio advenit - quando vocatio, certiorem clientem applicationis de hoc ut possit uti numerus vocatoris eum invenire in database in counterparte et informationes usoris de vocatione counterparty ostendere. Vel, exempli gratia, cum in horreis ordo pervenerit, de hac applicatione clientis certiorem facias. In genere sunt multi casus ubi talis machinatio utilis esset.
Productio ipsum
Nuntius creare mechanism. Ieiunium, certa, cum partus certo, cum facultate per nuntios quaerere mollius. Fundatur in mechanismo, efficiendi nuntius (nuntii, video vocat) intus 1C applicationes accurrens.
Designabis systema scalable horizontaliter esse. Crescente onere tegendum est numerum nodis augendo.
Реализация
Placuit non servo partem SV directe in suggestum 1C:Inceptum integrare, sed ad illud efficiendum ut productum separatum, cuius API e codice solutionum applicationis 1C vocari potest. Hoc multis de causis factum est, quarum praecipuarum erat quod epistulas inter alia applicationes 1C commutare posse volui (exempli gratia, inter Trade Management et Accounting). Applicationes 1C variae currere possunt in variis versionibus 1C:Incepti suggesti, in diversis servientibus collocari, etc. His conditionibus, exsequendum SV ut productum separatum "in parte" 1C institutionum positum est optima solutio.
Itaque constituimus ut productum separatum SV faceremus. Commendamus parvas societates ut servo CB utantur quod in nube nostra instituimus (wss://1cdialog.com) ad vitandum supra caput gratuita cum loci institutione et configuratione servientis consociata. Magnae clientes id expedire possunt ut CB servers suas in facultates suas instituat. Similem accessionem in nube SaaS producto usi sumus - producitur ut massa-productum ad institutionem in sitibus clientium, explicatur etiam in nube nostra. .
application
Ad tolerantiam oneris et culpae distribuendam, non unam applicationem Javam, sed plures cum onere librario ante illas explicabimus. Si nuntium e nodi ad nodi transferre debes, utere evulgare/subscribe in Hazelcast.
Communicatio inter clientem et ministrum via websocket est. Optime convenit systematibus realibus temporis.
Distribuit cache
Elegimus inter Redis, Hazelcast et Ehcache. Est MMXV. Redis modo novum botrum emisit (nimium novum, scary), vigil cum multa restrictione est. Ehcache nescit quomodo in botrum congregetur (quae officiatio postea apparuit). Nos cum Hazelcast 2015 experiri decrevimus.
Hazelcast in botrum e archa congregata est. Uno modo nodi, non valde utile est ac solum uti cella - nescit TUBER notitias orbis, si solum nodi perdis, datam amittis. Plures Hazelcasts explicamus, inter quas notitia critica tergum suppeditamus. Latibulum non restituimus – non sapimus.
Pro nobis Hazelcast est;
- Repono sessiones usoris. Longum tempus est ire ad singulas sessiones datorum, ita omnes sessiones in Hazelcast ponimus.
- Cache. Si quaeris profile usoris, latibulum reprehendo. Epistulam novam scripsit - in cella posuit.
- Argumenta communicationis inter Instantias applicationes. Nodus rem generat et in loco Hazelcasti collocat. Aliae applicationes nodis huic argumento subscriptae accipiunt et eventum explicant.
- Botrus cincinni. Exempli gratia, disputationem unam clavem unicam (disceptationem 1C datorum) creamus;
conversationKeyChecker.check("БЕНЗОКОЛОНКА");
doInClusterLock("БЕНЗОКОЛОНКА", () -> {
conversationKeyChecker.check("БЕНЗОКОЛОНКА");
createChannel("БЕНЗОКОЛОНКА");
});Nullam id varius sapien. Seram cepimus, iterum repressimus, et creavimus. Si seram post seram non inspicias, tunc facultas est ut aliud linum etiam tunc temporis inhibeatur et nunc eandem discussionem creare conabitur — sed iam exstat. Uti synchronised vel regularibus Java Obfirmo uti non potes. Per datorum - tardus est, et miseratio datorum, per Hazelcast - id est quod debes.
Eligens DBMS
Magnam et prosperam experientiam habemus cum PostgreSQL laborantem et cum cyclis huius DBMS collaborandam.
Non facile est cum botro PostgreSQL - est , , sed fere hi non NoSQLs e pyxide scandunt. Nos NoSQL ut tabularium principale non consideravimus, satis erat quod Hazelcast cepimus quod antea non laboravimus.
Si scandere debes relationis database, quod significat . Ut nostis, cum Sharing datorum in partes singulas dividimus, ut singulae singulae in servo separato collocari possint.
Prima versio nostra sharding facultatem assumpsit distribuendi singulas tabulas applicationis nostrae per diversos ministros in diversis proportionibus. Multae epistulae in servo A - amabo, partem huius tabulae moveamus ad servitorem B. Hoc consilium simpliciter exclamavit de praematuro optimizatione, ut nos ad multi-tenentem accessum circumscribere decrevimus.
De multi-tenente legere potes, exempli gratia, in pagina .
SV conceptus applicationis et subscribens habet. Applicatio est certae institutionis negotii applicationis, ut ERP seu Accounting cum suis usoribus et negotiis datorum. Subscribit regiminis vel individui cuius pro applicatione in SV server relatus est. Signator plures applicationes descripserunt habere potest, et hae applicationes nuntiis inter se permutare possunt. Signator factus est in nostra ratione tenens. Epistulae a pluribus signatoribus in uno datorum physicarum collocari possunt; si videmus signatorem multum negotiationis generare coepisse, nos movemus ad database separatum physicum (vel etiam servo datorum separato).
Praecipuum database habemus ubi mensa fuso reposita est cum informatione de loco omnium datorum subscribentium.
Ad principale datorum ne lagenarium esse prohibeamus, fusuram mensam (et alia notitia frequentius necessaria) in cella custodimus.
Si datorum subscribentium tardius incipit, eam in saepta intus incidemus. In aliis inceptis utimur .
Cum nuntiis utentis amissis malum est, nostras databases cum replicationibus conservamus. Coniunctio synchronae et asynchronae replicationum permittit tibi ut te praebeas in casu amissionis database principalis. Nuntius iactura tantum fiet si primaria database eiusque replica synchrona simul deficiunt.
Si figura synchrona periit, effigies asynchrona synchrona fit.
Si principalis database amittitur, figura synchrona fit principale database, et imago asynchrona synchrona fit effigies.
Elastica investigationis
Cum, inter alia, etiam nuntius SV est, requirit ieiunium, opportunum et flexibile perscrutatio, morphologiam ratione habita, cum paribus definitis. Non placuit rotam refricare et libera inquisitione elastica investigationis uti, quae in bibliotheca condita est . Elasticam investigationem in botro (domini - datae datae) explicamus ut difficultates tollantur in eventu nodum applicationis defectus.
In github invenimus pro elastica inquisitione et eo utere. In indice elastica inquisitionis radices verbi (quod plugin determinat) et N-gram condimus. Cum usor textum ad quaerendum ingreditur, textum generum apud N-gram exspectamus. Cum indicem servatum, verbum "textus" in P. N-sequentes dividetur:
[ea, tek, tex, text, texts, ek, ex, ext, texts, ks, kst, ksty, st, sty, te].Et radix vocabuli "textus" etiam conservabitur. Accessus hic permittit ut ab initio, in medio, et in fine verbi perspicias.
In altiore picture
Itera mancum ab initio articuli, sed cum explicationibus;
- Librarius in Interreti expositus; we have nginx, ullus esse potest.
- Javae instantiae applicabiles per Hazelcast inter se communicant.
- Ad opus nervum telae utimur .
- Applicatio Java scripta in 8 Java et ex fasciculis consistit . Consilia migrationis ad Javam 10 et transitum ad modulos includunt.
Development nostris temptatum
In processu enucleandi et experiendi SV, invenimus per aliquot lineamenta interesting productorum utimur.
Onus probatio et memoria pinum
Emissio cuiusque SV emissio oneris probatio involvit. Res bene habet;
- Expertus aliquot dies laboravit et nulla opera cessaverunt
- Responsio tempus key operationes commoda limina non excedunt
- Facis depravatio comparatur ad priorem versionem non plus quam X%
Experimentum datorum cum notitia implemus - ad hoc faciendum, informationes accipimus de subscribente promptissimo e servo productionis, multiplicando numeros suos per V (numerum epistularum, discussionum, usorum) et hoc modo probamus.
Nos onus exercemus experimentum systematis commercii in tribus configurationibus:
- accentus test
- Connectiones solum
- subscriptores registration
In accentus test, plura centum stamina immittimus, et systema sine intermissione onerant: nuntiis scribo, disputationibus creando, indicem epistularum accipiendo. Simulamus actiones usorum ordinariorum (indicem praebe nuntiorum meorum illectum, alicui scribe) et solutionum programmatum (transmittunt sarcinam diversae configurationis, acris processus).
Exempli gratia, haec pars accentus test similis est:
- User acta in
- Petitiones tuas illecta disputationibus
- L% verisimile legere nuntios
- L% verisimile text
- Proxima usor:
- Habet XX% casu de creando novam disputationem
- Passim eligat aliquem ex suis disputationibus
- It intus
- Mandata postulata, perfiles usoris
- Quinque nuntios ad users temere ex hac disputatione creat
- Disceptatio relinquit
- Repetit XX temporibus
- Acta publicata, redit ad principium scriptionis
- A chatbot intrat systema (emulatur quantitatem ex codice application)
- Habet L% facultas creandi novum alveum suum pro notitia commutationem (specialis discussion)
- L% verisimile scribere nuntium cuilibet existentium channels
"Connexiones Solae" apparuerunt causa missionis. Locus est: utentes systema contexunt, sed implicatum nondum habent. Uterque usor se in computatro ad 09:00 in mane vertit, nexum cum servo constituit et silet. Haec guys periculosa sunt, multae ex iis sunt - solae fasciculi quas habent PING/PONG sunt, sed nexum servo custodiunt (id servare non possunt - quid si nuntius novus est). Expertus exprimit condicionem ubi numerus talium utentium conetur ut systema media horae aperiat. Similis est cum experimento accentus, sed focus in hoc primo initus est - ita ut nulla sint delicta (qui ratio non utitur, et iam defluit - difficile est de deterius cogitare).
Subscribens adnotatione scriptor incipit a primo launch. Experimentum accentus deduximus et certo certius erat systema in correspondentia non retardare. Sed utentes venerunt et adnotationem deficere incepit propter tempus. Cum perscriptum essemus quod se habet ad entropam systematis. Servus tempus satis entropy accumulandi non vacavit et cum novus SecureRandom rogatus est, decem secundis adligat. Multi modi ex hoc situ sunt, exempli gratia: commutandum ad minus securum /dev/urandom, specialem tabulam institue quae entropy generat, temere numeros in antecessum generant et eas in piscina condunt. Difficultatem ad tempus piscinae clausimus, sed quia tunc separatum experimentum novum subscribentium perscriptum fuerimus.
Utimur quasi onus generantis . Non scit quomodo laborare cum websocket, plugin indiget. Prima in quaestionibus eventis pro interrogatione "jmeter websocket" sunt: , quam commendo .
Id ubi incipere constituimus.
Fere statim post gravem probationem inceptis compertum habemus JMeter memoriam rimari coepisse.
Plugin magna fabula separata est, cum 176 stellis, 132 furcas in github habet. Auctor ipse ei cum 2015 non commisit (quam anno 2015 cepimus, suspiciones deinde non excitavit), plures quaestiones github de memoria effluo, 7 petitiones reclusas collige.
Si onus tentationis hoc plugin utendo praestare volueris, sequentibus disputationibus operam da:
- In ambitu multi-filato, LinkedList ordinarius adhibitus est, et effectus erat in runtime. Id solvi potest vel mutando ad ConcurrentLinkedDeque vel per stipites synchronizatos. Primam optionem pro nobis elegimus.).
- Memoria Leak, cum disiunctio, notitia nexus non deleta est ().
- In modo effusis (cum websocket in fine exemplaris non clauditur, sed postea in consilio adhibetur), Responsio exemplaria non operantur ().
Hic est unus illorum in github. Quod fecimus;
- Sumpta (@elyrank) - determinat difficultates 1 et 3
- Solvitur quaestio 2
- Renovata nigricans ex 9.2.14 ad 9.3.12
- SimpleDateFormat in ThreadLocal convoluta; SimpleDateFormat non est sequela, quae NPE ad tempus ducitur
- Aliam memoriam fixa Leak (connexio claudebatur perperam disiuncta)
Et tamen fluit!
Memoria non uno die, sed duobus modis excurrere coepit. Nullum tempus omnino relictum erat, ut pauciores stamina mittere decrevimus, sed quattuor agentibus. Hoc satis esse debet saltem per hebdomadam.
Biduo ...
Nunc Hazelcast e memoria currit. Tigna ostendebant post biduum tentationis, Hazelcast queri de defectu memoriae incepit, et post aliquod tempus botrus decidit, et nodos per singula mori perstitit. JVisualVM ad corulae conteximus et "vidit orientem vidi" - regulariter GC appellavimus, sed memoriam non potuimus declarare.
Evenit ut 3.4 in corylo, cum delendo chartam / multiMap (map.destroy()), memoria non omnino liberata est;
Cimex nunc in 3.5 fixus est, sed tunc quaestio erat. Novas multiplices nomina dynamicas creavimus easque secundum logicam nostram delevimus. In codice aliquid simile hoc vidi:
public void join(Authentication auth, String sub) {
MultiMap<UUID, Authentication> sessions = instance.getMultiMap(sub);
sessions.put(auth.getUserId(), auth);
}
public void leave(Authentication auth, String sub) {
MultiMap<UUID, Authentication> sessions = instance.getMultiMap(sub);
sessions.remove(auth.getUserId(), auth);
if (sessions.size() == 0) {
sessions.destroy();
}
}Vocare:
service.join(auth1, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");
service.join(auth2, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");multiMap pro singulis subscriptionibus creata sunt et deleta cum opus non erat. Statuimus nos ut Map incipiamus , clavis nomen subscriptionis erit, ac valores identificatores erunt (ex quibus identificatores, si opus est, tunc obtinere potes).
public void join(Authentication auth, String sub) {
addValueToMap(sub, auth.getSessionId());
}
public void leave(Authentication auth, String sub) {
removeValueFromMap(sub, auth.getSessionId());
}In melius chartis.
Quid aliud de onere tentationis didicimus?
- JSR223 in groovy scribendae sunt et in compilatione cache includit - multo citius est. .
- Jmeter-Plugins graphs faciliores sunt ad intelligendum quam regulas. .
De nostra experientia apud Hazelcast
Hazelcast novum productum pro nobis fuit, cum eo e versione 3.4.1 operari coepimus, nunc ministra productio nostra 3.9.2 currit versio (tempore scribendi, postrema versio Hazelcast est 3.10).
ID generation
Integer identificantes coepimus. Fingamus nos aliam egere rem novam desiderare. Sequentia in datorum non convenit, tabulae obstringuntur in shards — evenit ut nuntius ID=1 in DB1 et nuntius ID=1 in DB2, hoc ID in Elastica investigatione ponere non possis, neque in Hazelcast. sed pessimum est si vis notitias ex duobus databases in unum coniungere (exempli gratia, quod unum datorum sufficit his signatoribus). Plures atomicLongs addere potes ad Hazelcast et occurri ibi serva, deinde perficiendi novum ID obtinendi est incrementAndGet plus temporis pro petitione Hazelcast. Sed Hazelcast melius aliquid habet - FlakeIdGenerator. Cum clientem quemque contingunt, datae sunt ID range, exempli gratia, prima – ab 1 ad 10, secunda – ab 000 ad 10, et sic porro. Nunc cliens novos identificatores per se edicere potest donec distributio finiatur. Celeriter operatur, sed cum applicatione sileo (et Hazelcast cliens), nova series incipit - Hinc vagatur, etc. Praeterea tincidunt non intellegunt cur IDs integri sint, sed tam pugnant. Omnia appendimus et ad UUIDs transivimus.
Obiter iis qui Twitter similes esse volunt, talis bibliotheca est Snowcast - haec est exsecutio Snowflake super Hazelcast. Inspicere potes hic:
Sed circumire non potuimus amplius.
TransactionalMap.replace
Alius mirum: TransactionalMap.replace non operatur. Hic est temptare:
@Test
public void replaceInMap_putsAndGetsInsideTransaction() {
hazelcastInstance.executeTransaction(context -> {
HazelcastTransactionContextHolder.setContext(context);
try {
context.getMap("map").put("key", "oldValue");
context.getMap("map").replace("key", "oldValue", "newValue");
String value = (String) context.getMap("map").get("key");
assertEquals("newValue", value);
return null;
} finally {
HazelcastTransactionContextHolder.clearContext();
}
});
}
Expected : newValue
Actual : oldValueHabui scribere mea reponere utens getForUpdate:
protected <K,V> boolean replaceInMap(String mapName, K key, V oldValue, V newValue) {
TransactionalTaskContext context = HazelcastTransactionContextHolder.getContext();
if (context != null) {
log.trace("[CACHE] Replacing value in a transactional map");
TransactionalMap<K, V> map = context.getMap(mapName);
V value = map.getForUpdate(key);
if (oldValue.equals(value)) {
map.put(key, newValue);
return true;
}
return false;
}
log.trace("[CACHE] Replacing value in a not transactional map");
IMap<K, V> map = hazelcastInstance.getMap(mapName);
return map.replace(key, oldValue, newValue);
}Probare non solum structuras datas regulares, sed etiam versiones transactionales eorum. Contingit opera IMap, sed TransactionalMap non iam exstat.
URNA nova inserere sine downtime
Primum objecta classium nostrarum in Hazelcast commemorare decrevimus. Exempli gratia, genus applicationis habemus, servare et legere volumus. Salvare:
IMap<UUID, Application> map = hazelcastInstance.getMap("application");
map.set(id, application);Legitur:
IMap<UUID, Application> map = hazelcastInstance.getMap("application");
return map.get(id);Omnia laborat. Tum indicem in Hazelcast pervestigare decrevimus:
map.addIndex("subscriberId", false);Et cum novam entitatem scribentes, ClassNotFoundExceptionem recipere inceperunt. Hazelcast indicem addere conatus est, sed de genere nostro nihil noverat et cum hoc genere URNA suppleri voluit. Fecimus hoc modo, omnia operata, sed nova quaestio apparuit: quomodo urnam renovare sine botro penitus intermisso? Hazelcast nova URNA in nodi renovatio non colligit. Hic decrevimus ut sine indice inquisitionis vivere possemus. Post omnia, si Hazelcast uteris ut clavem pretii, omnia operabuntur? Non realiter. Hic rursus mores IMap et TransactionalMap diversae sunt. Ubi IMap non curat, TransactionalMap errorem inicit.
IMap. Scribimus objecta 5000, lege illa. Omnia exspectentur.
@Test
void get5000() {
IMap<UUID, Application> map = hazelcastInstance.getMap("application");
UUID subscriberId = UUID.randomUUID();
for (int i = 0; i < 5000; i++) {
UUID id = UUID.randomUUID();
String title = RandomStringUtils.random(5);
Application application = new Application(id, title, subscriberId);
map.set(id, application);
Application retrieved = map.get(id);
assertEquals(id, retrieved.getId());
}
}Sed in transactione non operatur, ClassNotFoundException accipimus:
@Test
void get_transaction() {
IMap<UUID, Application> map = hazelcastInstance.getMap("application_t");
UUID subscriberId = UUID.randomUUID();
UUID id = UUID.randomUUID();
Application application = new Application(id, "qwer", subscriberId);
map.set(id, application);
Application retrievedOutside = map.get(id);
assertEquals(id, retrievedOutside.getId());
hazelcastInstance.executeTransaction(context -> {
HazelcastTransactionContextHolder.setContext(context);
try {
TransactionalMap<UUID, Application> transactionalMap = context.getMap("application_t");
Application retrievedInside = transactionalMap.get(id);
assertEquals(id, retrievedInside.getId());
return null;
} finally {
HazelcastTransactionContextHolder.clearContext();
}
});
}Anno 3.8, instruere mechanismum Classis Usoris apparuit. Unum nodi dominum designare potes et tabellam URNA in ea renovare.
Iam appropinquationem nostram penitus mutavimus: nosmetipsos in JSON inspicimus et in Hazelcast servamus. Hazelcast structuram nostrorum generum cognoscere non indiget, et sine temporis spatio renovare possumus. Versiones dominiorum obiecti applicatione refrenat. Variae applicationis versiones simul currere possunt, et condicio fieri potest cum nova applicatione res cum novis agris scribit, sed vetus nondum de his agris cognoscit. Eodemque tempore nova applicationis obiectis per veterem usum scriptam legit, quae novos agros non habet. Talibus in applicatione adiunctis tractamus, sed pro simplicitate agros non mutamus nec delemus, tantum classes novas agros augendo augemus.
Quomodo nos curare altum perficientur?
Quattuor itinera ad Hazelcast - bona, duo datorum - mala
Perge ad cella pro notitia semper melior quam ad datorum eundi, sed nec insueta monumenta condere vis. Consilium de rebus condiendis usque ad ultimum evolutionis stadium relinquimus. Cum nova functionalitas coded est, omnia quaerenda in PostgreSQL (log_min_duration_statement ad 0) colligationem convertimus et onus experimentum per 20 minuta currunt. Usura congesta, utilitates sicut pgFouine et pgBadger analyticas relationes aedificare possunt. In relationibus imprimis quaerendo tardas et crebras quaerimus. Pro tarda quaestionibus, consilium exsecutionis aedificamus (EXPLAIN) et aestimamus num talis quaestio accelerari potest. Crebrae petitiones eiusdem initus notitiae bene aptae in cella. Quaesitum "planum" servare conamur, una mensa per quaesitum est.
Quaestus
SV sicut ministerium online in fonte MMXVII operatum est, et quasi productum separatum, SV mense Novembri 2017 dimissum est (tunc in beta versionis status).
Plus quam annus laboris, nullae graves quaestiones in operatione CB officii online factae sunt. Nos Monitor online ministerium via Colligunt et explicant e .
SV server distributio suppleta est forma fasciculorum indigenarum: RPM, DEB, MSI. Plus pro Fenestra unum installer in forma EXE unius praebemus, qui servo, Hazelcast et elasticationem in una machina inaugurat. Hanc versionem institutionis tamquam "demo" versionem initio rettulimus, sed nunc patefit hanc optionem instruere maxime popularem.
Source: www.habr.com