Příspěvky

3301

Vývoj / Re:Thread-Safe List v jave

« kdy: 04. 06. 2018, 09:09:36 »

Synchronizované musí být zdroje, ke kterým se přistupuje z více vláken

No prave, to v pripade Listu v mape bude nie? Ako som spominal ak uzivatel spusti aplikaciu na viacerych miestach zaroven, tak tie deferred resulty sa budu pridavat z viacerych vlaken.

Ano, ale ten přístup bude synchronizovaný přes mapu. Zapisovat se do toho listu bude pouze v rámci volání metody compute, která zajistí synchronizaci, a číst se bude až po zavolání remove na mapě, takže ten list pak bude ve vlastnictví jednoho vlákna a ostatní už k němu nebudou mít přístup.

3302

Vývoj / Re:Thread-Safe List v jave

« kdy: 04. 06. 2018, 07:11:34 »

zaznamy unikatne predsa nebudu, pretoze uzivatel moze otvorit aplikaciu v novom okne, tie data sa posielaju automaticky, cize duplicity vznikat budu, a je potreba reagovat na vsetky, nemoze sa stat, ze aplikacia zobrazi v jednom okne ine vysledky ako v tom druhom

Záznamy unikátní budou, protože záznamem je asynchronní požadavek a ten vznikne pokaždé nový.

kazdopadne dakujem za radu, cize naozaj staci obycajny linked list nesynchronizovany? myslel som ze ak sa vyuziva multithreading musia byt synchronne aj vnorene kolekcie v mape

Synchronizované musí být zdroje, ke kterým se přistupuje z více vláken. A v případě ConcurrentHashMap zajistí synchronizaci metoda compute, která se pro daný klíč provádí atomicky.

3303

Vývoj / Re:Thread-Safe List v jave

« kdy: 03. 06. 2018, 23:49:14 »

ak pridu nove data od nejakeho uzivatela, vezme sa priznak z tych dat, pozrie sa ci mapa obsahuje nejake "cakajuce" requesty, teda uzivatelov ktory cakaju na tieto data, ak ano iteraciou sa kazdemu deferred resultu v kolekcii nastavia dane data

Takže se to má nastavit všem objektům pro daného uživatele a na pořadí nezáleží. A po nastavení dat se předpokládám celá kolekce smaže (respektive kvůli vícevláknovému přístupu by spíš měla naopak nejdřív vyjmout z mapy, aby už se neměnila, a pak nastavit výsledky). V tom případě by stačil Set, ale protože unikátnost je zaručená z povahy věci a není nutné ji kontrolovat, z hlediska výkonu bude asi lepší LinkedList. Buď tedy ConcurrentLinkedQueue, a nebo použít ConcurrentHashMap a její metodu compute a uvnitř už pak běžný nesynchronizovaný LinkedList – to si myslím, že bude v tomto případě nejefektivnější řešení.

3304

Vývoj / Re:Thread-Safe List v jave

« kdy: 03. 06. 2018, 23:22:45 »

kazdopadne otazka nebola aku technologiu zvolit ale aku kolekciu pouzit pre dany problem

Pořád ještě nevíme, jak se z té kolekce bude číst, bez toho se opravdu nedá určit, jakou kolekci použít a zda vůbec použít kolekci.

Navíc pokud nevíte, jakou kolekci použít, měl by vám to snad říci ten vedoucí, ne…

3305

Vývoj / Re:Thread-Safe List v jave

« kdy: 03. 06. 2018, 22:26:18 »

No a jak se pozná to, že už data pro uživatele jsou? A jak budete hledat response, ke kterému ta data patří?

iny uzivatel odosle data na server kde je priznak prijimatela, na zaklade ktoreho su data v mape

Podle toho se vybere klíč v mapě. A položka v seznamu se vybere jak? Má to být fronta, takže vždy první položka?

Pokud se s odpovědí čeká na jiného uživatele, asynchronní requesty podle mne nejsou dobrá volba. Použil bych ty WebSokety, ty jsou na takovouhle komunikaci přesně určené. Ve Springu je nad tím podpora pro protokol STOMP, případně od Webtide existuje CometD, které lze také propojit se Springem. Obojí řeší předávání zpráv konkrétním posluchačům, takže nemusíte řešit právě to, které spojení je kterého uživatele.

3306

Odkladiště / Re:Airbank web a javascript event listener místo obyčejného odkazu

« kdy: 03. 06. 2018, 22:15:12 »

Tak třeba ty sociální ikony jsou opravdu tlačítka, takže tam to jinak než přes událost udělat nelze. A bude to tak nejspíš proto, že to nějaký marketingový nástroj pro sledování prokliků od Adobe generuje… Jak je to v jejich IB netuším, nicméně může to být, že uživatelé by nepochopili, že když něco udělají v jednom okně, v druhém zůstane starý stav, tak jim to raději zakážeme.

3307

Vývoj / Re:Thread-Safe List v jave

« kdy: 03. 06. 2018, 22:01:19 »

Len aby sme sa spravne pochopili, tymi requestmi myslim deferred result objekty. ak uzivatel posle poziadavok na data, vytvori sa pre daneho uzivatela deferred result a ulzi sa do kolekcie az kym nie su pre neho nove data. Ako nahle su, tak sa deferred result objektu nasetuju dane data a ten sa potom vrati uzivatelovi ktory sa na ne poptaval. Deferred result sa potom zmaze pre daneho uzivatela z mapy.

No a jak se pozná to, že už data pro uživatele jsou? A jak budete hledat response, ke kterému ta data patří?

Jinak pokud je to asynchronní webový kontrolér, pozor na to, že tam je ta asynchronnost určená pro to, aby se zbytečně neblokovalo vlákno třeba při čekání na data z databáze nebo z nějaké webové služby, tedy pro věci, které by měly být vyřízené během pár vteřin. Z pohledu prohlížeče/klienta je to pořád synchronní komunikace, takže jakmile prohlížeč odešle poslední bajt požadavku, zapne stopky a měří timeout do prvního bajtu odpovědi – a pokud se nedočká ve stanoveném limitu, spojení resetuje a zobrazí chybu.

Pokud byste chtěl skutečně asynchronní komunikaci (např. chat), kde odpověď může přijít třeba za 5 nebo taky za 15 minut, je potřeba použít buď Server-sent events nebo WebSockets. Pro WebSockety má Spring také dobrou podporu včetně fallbacku pro staré prohlížeče, které WebSockety nepodporují.

3308

Vývoj / Re:Thread-Safe List v jave

« kdy: 03. 06. 2018, 21:05:45 »

Vyuziva sa trieda zo springu deferred result, ktora zabezpeci to, aby dany objekt bol vrateny ako response az ked sa mu nastavi result. Tym ze tieto objekty drzim v kolekcii, mozem im nastavit result kedy to je potrebne, a vtedy je vysledok vrateny uzivatelovi.

To ale pořád není důvod držet requesty v kolekci. Přece nějak zjistíte, že máte co uživateli vrátit – buď na to čekáte, tak můžete mít ten deferred result uložený u toho čekání, nebo ty odpovědi chodí nějak úplně nezávisle (např. na chatu – „pošli zprávu uživateli XY“), ovšem pak zase musíte umět identifikovat, kam se má poslat ta odpověď, a hodila by se spíš mapa, kde by byl klíč ten identifikátor a hodnota ten response. Netvrdím, že nemůže být případ, kde je vhodné použít list, ale nic moc takového mne nenapadá. Snad jen kdybyste chtěl uživateli zobrazit frontu jeho požadavků, jak postupně přicházely, nebo chtěl postupně v pořadí zpracovat všechny požadavky uživatele. Ale to neodpovídá tomu deferred result.

3309

Vývoj / Re:Thread-Safe List v jave

« kdy: 03. 06. 2018, 20:43:07 »

Data ulozene v liste maju predstavuju asynchronne requesty uzivatelskych aplikacii, teda tymto ulozenym requestom sa nastavuje response, a nasledne je vystup vrateny aplikacii.

Pořád nechápu, proč by ty requesty měly být uložené zrovna v listu. Co s těmi requesty budete dělat? Jak vznikne response k danému requestu?

3310

Vývoj / Re:Thread-Safe List v jave

« kdy: 03. 06. 2018, 18:40:22 »

Nemozem uz priamove volat computeIfAbsent ja v danej triede namiesto obalovania dalsim objektom?

Můžete, ale pak musíte zajistit, že se prvky do mapy budou vkládat vždy správným voláním computeIfAbsent, nikdo nikdy nezavolá třeba put nebo jinou metodu pro přidání prvku do mapy. Než to hlídat na všech místech, kde by se to mohlo použít, je lepší tu mapu zapouzdřit do vlastního objektu, ze kterého se vystaví jenom metoda pro přidání hodnoty do mapy, a ta metoda už si sama zajistí, aby to přidání proběhlo správně. To je přesně důvod, proč se používá OOP.

S datami sa bude pracovat nasledovne:
Uzivatel A spusti aplikaciu, cim sa vytvori zaznam, kde key bude nejake id uzivatela, a nejake metada sa ulozia do Listu. Problem vsak je, ak otvori danu aplikaciu ten isty uzivatel na novej karte, v novom okne, casom mozno pribudne iny typ aplikacie, takze uzivatel bude prihlaseny na viacerych miestach naraz, co opat vyvola ulozenie metadat na zaklade id uzivatela do mapy. Preto metadata treba ukladat do kolekcie.

Taktiez moze nastat situacia, kedy uzivatel B, spusti nejaku akciu, ktora potrebuje metada uzivatela A, ta akcia pouzije vsetky metada priradene ku klucu uzivatela A, v iteracii nad kazdym zaznamom vykona nejaku operaciu, a nasledne sa z mapy odmaze kluc aj s metadatami uzivatela A.

Používat na tohle list mi tedy připadá dost divoké. Spíš bych do té mapy dával vlastní objekt představující přihlášeného uživatele, který bude poskytovat vlastní služby – vyhledání metadat pro danou aplikaci, odhlášení od aplikace apod. Protože třeba to procházení listu není atomická operace, a když k tomu budete přistupovat z více vláken, může se vám stát, že z jednoho vlákna ten prvek z listu smažete, ale v druhém vlákně ten prvek třeba budete modifikovat. List se tím nepoškodí a nakonec z něj ten prvek bude smazán, ale je otázka, zda je správné chování aplikace, která jeden záznam zároveň mění i maže.

Trosku som sa vam pokusil objasnit pre aku pracu potrebujem dany List, je pre tento pripad vhodny spominany CopyOnWriteArrayList alebo siahnut po niecom inom ?

To pořád závisí na poměru počtu zápisů k počtu čtení těch listů a třeba také na jejich velikosti. Což z toho vašeho popisu není patrné. Ale podle toho, jak jste to popsal, bych tam vůbec nedával list.

3311

Server / Re:Ako vyriesit www a non www na apache2

« kdy: 03. 06. 2018, 18:14:10 »

Mam to chapat tak, ze 1 a 3 dmona su domeny stvrteho radu a prostredna domena je tretieho radu ?

Ano.

A ked chcem aby sa mi zobrazovalo to iste pod vsetkymi menami, tak si musim vytvorit konfiguraky pre 3 virtualhosty a v kazdom pouzit iny ServerName a inu cestu pre DocumentRoot a 3 adresare s rovnakym obsahom ?

Stačil by jeden adresář a do něj nasměrovat všechny tři DocumentRoot. Na chybových stránkách by se vám pak ukazoval pro každou doménu správný název serveru. Nebo byste mohl všechny tři domény dát do jednoho virtualhostu, jeden název zvolit jako hlavní a použít pro ServerName a zbylé dva dát do ServerAlias. Pak by se na chybových stránkách zobrazovalo všude to ServerName. Ale také byste mohl ty chybové stránky upravit, aby se pro výpis názvu serveru nepoužívala proměnná SERVER_NAME ale HTTP_HOST, a pak by se zase na chybových stránkách zobrazoval název serveru odpovídající požadované doméně. Pokud tedy klient pošle správnou hlavičku (což dnes všechna prohlížeče dělají). Ono se to historicky různě vyvíjelo, takže dnes existuje třeba víc postupů, jak dosáhnout téhož, přičemž se ty postupy liší v nějakých okrajových případech.

Každopádně mít stejný obsah na více doménách by bylo matoucí pro uživatele i pro vyhledávače, takže bych se snažil tomu vyhnout. Obsah (DocumentRoot) bych dal na jednu doménu (jeden virtual host), a z těch zbývajících domén bych udělal přesměrování (druhý virtualhost).

Kód: [Vybrat]

<VirtualHost *:80>
    ServerName nieco.ddns.info
    ServerAlias abc.nieco.ddns.info

    RewriteEngine on
    RewriteRule ^(.*)$ http://www.nieco.ddns.info$1 [R=301,NE,L]
</VirtualHost>

<VirtualHost *:80>
    ServerName www.nieco.ddns.info

    DocumentRoot /var/www/www.nieco.ddns.info
</VirtualHost>

3312

Vývoj / Re:Thread-Safe List v jave

« kdy: 03. 06. 2018, 17:54:32 »

Kterou konkrétní implementaci vybrat záleží na tom, jakým způsobem se bude s daty pracovat. Pokud se bude z listu často paralelně číst, a jenom výjimečně do něj zapisovat, hodí se CopyOnWriteArrayList. Pokud se do listu bude běžně zapisovat, je lepší použít ConcurrentLinkedQueue nebo ConcurrentLinkedDequeue.

Celou mapu byste pak měl zapouzdřit do vlastního objektu, který bude mít např. metodu pro přidání položky a interně zavolá computeIfAbsent pro vytvoření listu, pokud ještě neexistuje, a pak do listu přidá hodnotu. Pokud je cílem multimapa, tj. mapa, která může mít pro jeden klíč víc hodnot, a stačí tedy tento slabší přístup k zamykání. Pokud by byl potřeba výhradní přístup k dané dvojici klíč:seznam, bylo by potřeba použít metodu compute.

3313

Vývoj / Re:Thread-Safe List v jave

« kdy: 03. 06. 2018, 16:48:00 »

Proč nechcete použít některou z implementací ve standardní knihovně? A počítáte s tím, že použití thread-safe listu v thread-safe mapě ještě automaticky nezaručuje thread-safe použití jako celku?

3314

Server / Re:Ako vyriesit www a non www na apache2

« kdy: 03. 06. 2018, 14:31:46 »

Pro koncové vlastníky jsou obvykle určené domény druhého řádu – třeba v TLD (top level domain, doména nejvyšší úrovně) sk, cz, com, org atd. Ale jsou i domény, kde je to jinak – třeba v doméně uk se až do roku 2014 registrovaly jen domény 3. úrovně pod doménami co.uk, org.uk a několika dalšími. Pokud nějaká organizace poskytuje další služby zdarma a poskytuje k nim samostatnou doménu, bývá to na doméně třetího řádu, protože tam už můžou své domény vytvářet „zdarma“ – to je případ třeba toho ddns.com, nebo je možné si takhle vytvářet jednoduché webové stránky pod doménou webnode.cz.

www.example.com je doména třetího řádu nebo také hostname. Dříve bylo zvykem takhle rozlišovat typ služby – třeba www.example.com pro web, ftp.example.com pro webový server, pop3.example.com pro poštovní server… Jenže tím, jak internet je hlavně web, pak dlouho dlouho nic a pak další služby, začalo se někomu zdát to www zbytečné a dnes se pro web běžně používá i varianta bez www (a naopak je považováno za chybu, pokud ta varianta neexistuje, alespoň ve formě přesměrování).

Jestli se přesměrovává z www.example.com na example.com nebo opačně je na uvážení majitele webu, kterou variantu si vybere jako základní.

V DNS musí být A záznamy pro oba názvy. Pokud už máte IPv6 adresu, měly by tam být i AAAA záznamy pro IPv6 protokol.

To ServerName a ServerAlias tam není kvůli přesměrování, ale proto, aby Apache věděl, že daná sekce VirtualHost se má použít právě v případě, kdy klient (prohlížeč) požaduje některé z těch jmen. Třeba v tom případě Google by tam ale byly dvě sekce – jedna s google.com, kde by bylo přesměrování, a druhá s www.google.com, kde už by byl samotný obsah. Dá se to spojit i do jedné sekce, ale připadá mi to nepřehledné. Rozdíl mezi ServerName a ServerAlias je v tom, aby server věděl, který název je primární a má ho použít třeba tehdy, když bude generovat chybovou stránku. ServerAlias pak serveru říká, že když bude klient požadovat daná jméno, má se také použít daná sekce, ale není to hlavní jméno toho webu. Dříve se to klidně nechávalo, že jste mohl jít na www.example.com i example.com a zobrazil se stejný obsah, ale nebylo tam přesměrování, dnes už se většinou používá přesměrování, aby jeden obsah měl právě jedno URL. ServerAlias ale sám o sobě přesměrování nezajistí.

3315

Server / Re:Ako vyriesit www a non www na apache2

« kdy: 03. 06. 2018, 12:05:20 »

Řekl bych, že tam máte buď jiný certifikát, nebo byl ten certifikát špatně vytvořen. Ale když neznáme skutečné jméno toho webu, nemůžu se na ten certifikát podívat, abych zjistil, kde přesně je problém.