reklama

Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - kvr kvr

Stran: 1 [2] 3 4
16
Vývoj / Re:Implementace long-polling v Javě (Spring)
« kdy: 17. 04. 2018, 23:35:48 »
K tomu scheludingu ...

Citace
Notice that the methods to be scheduled must have void returns and must not expect any arguments

Potrebujeme metode predat nejakej argument na zaklade ktereho ma rozpoznat nova data pro daneho uzivatele, cize to se asi pouzit neda.

Tak metoda (Runnable) má nějaký closure context, případně může mít instance variables. Zjednodušený example přes polling (poznámky o konstantách, špatných parametrech a jménech anotací prosím do /dev/null):

Kód: [Vybrat]
CompletableFuture<Message> notifyMessages(@SessionParam("username") String username) {
    CompletableFuture<Message> result = new CompletableFuture<>();
    long timeoutTimestamp = System.currentTimeMillis()+30000;
    Runnable checker = () -> {
        List<Message> messages = messageStore.loadMessages(username);
        if (messages.isEmpty()) {
            long nextSchedule = System.currentTimeMillis()+10000;
            if (nextSchedule >= timeoutTimestamp) {
                result.completeExceptionaly(new TimeoutException());
            }
            else {
               executor.schedule(checker, 10000);
            }
        }
        else {
             result.complete(messages);
        }
    }
    executor.schedule(checker, 10000);

    return result;
}

U messaging by se musel nastavit listener na message, který by zkompletoval future podle filtrovaného a zaregistrovaného username.

17
Vývoj / Re:Implementace long-polling v Javě (Spring)
« kdy: 17. 04. 2018, 21:55:11 »
Právě přes asynchronous request: https://nickebbitt.github.io/blog/2017/03/22/async-web-service-using-completable-future

A místo cyklu stačí vrátit CompletableFuture a naplánovat polling přes ScheduledExecutorService: https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ScheduledExecutorService.html#schedule(java.lang.Runnable,%20long,%20java.util.concurrent.TimeUnit) , s retry, když se nepovede (není výsledek) nebo failure při timeout.

DeferredResult je další možnost, který dokonce timeout přímo podporuje. Místo polling se dá interně použít třeba messaging, aby se zbytečně nezatěžoval ani server.

18
Podle vás je následující kód špatně?

Ano, je špatně. Správně má být:

Kód: [Vybrat]
public long increment(String name) {
  AtomicLong namedCounter;
  lock.readLock().lock();
  try {
    namedCounter = counter.get(name);
  } finally {
    lock.readLock().unlock();
  }
  return namedCounter.incrementAndGet();
}

19
Například v tomhle kódu vám to druhé vlákno může vypsat 0, 1 nebo i hodnotu, kterou měla ta položka ještě dříve.
Kód: [Vybrat]
Item item = synchronizedMap.get("item1");
item.setValue(0);
new Thread(() -> item.setValue(1)).start();
new Thread(() -> System.out.println(item.getValue())).start();

Nemůže. Může vypsat 0, 1 nebo hodnotu, kterou bude mít položka později. Nemůže vypsat dřívější, bo Thread.start() invokuje memory barrier (z hlediska JVM zajišťuje happened-before), podobně jako Thread.join().

20
Mně teda ale hlavně překvapuje, pokud tam Ondřej ty iterátory normálně používá, že to nikdy nevypadlo na ConcurrentModificationException. Že je to jenom taková nouzová pojistka, která ve vícevláknovém prostředí nemusí fungovat správně, je jasné, ale že se to netrefilo nikdy… Předpokládám, že modifikace toho setu probíhala z jiných vláken, než která používala ten iterátor, takže prostě každé vlákno mělo svou lokální hodnotu počtu modifikací a nikdy se to nepotkalo.

Je otázka, jak často iterator běhal ve srovnání s modifikacemi. Nicméně obecně, ConcurrentModificationException se detekuje podle počítadla modifikací a ten, než se zpropaguje z jednoho CPU cache do druhého, tak už je typicky dávno po iteraci...

21
Pokud se ti změní hashcode objektu který je již v Setu chová se to takto divně. Podívej se jak je implementován HashSet.

Modifikace objektu (respektive jeho hashCode) rozbije jeho vyhledávání, ale nikoliv iteraci (nebo statistiku size a isEmpty). Tedy záleží na implementaci, můžou existovat takové, které rozbijí i iteraci, ale v java.util HashSet, LinkedHashSet i třeba TreeMap stále fungovat budou.

22
A nevrací se buď přímo ten set nebo třeba jen iterátor někam mimo tu třídu, takže se k němu už přistupuje mimo synchronized? (teď nemyslím nutně ten testovací kód).

Jinak přelinkování objektů v HashSet/Map se může rozbít samo o sobě, pokud tam dělají dva thready něco zároveň, počítadla (včetně isEmpty()) to samozřejmě ještě zhorší.

A ano, ve chvíli, kdy se interní struktura rozbije jednou, tak se dohromady může dát už jenom stejnou (opačnou) náhodou (teď "mírně" zjednodušuju). Takže zůstane nejspíš rozbitá napořád.

Zkusil bych buď ConcurrentHashSet (tedy spíš zabalený Map) nebo Collections.synchronizedSet() ... Nebo spíš je otázka, proč něco, co se nazývá queue, je jenom Set a nikoliv (Blocking)Queue...

23
Vývoj / Re:Abuzus XML v Javě
« kdy: 13. 02. 2018, 06:18:40 »
Xsd je poměrně slabé na validaci dat, tak jednoduše hledají způsob, jak ho vylepšit.

S xml se dá udělat opravdu hodně dalších věcí, než jej uložit do SQL databáze přes hibernate, takže hibernate by zde byl zbytečná a možná i nedostatečná depedence. Navíc by se musel udělat nejspíš poměrně kompletní model daného xml, zatímco přes ten jejich nástroj (předpokládám) definují jenom handlery přes třeba xpath.

Poslední věc je, že validace není nejspíš vázána na konkrétní jazyk, takže se dá implementovat v kterémkoli jazyku a úrovní.

Kdysi jsem psal (komplexnější) framework, který validátor definoval přes anotace, ale exportoval je do klienta běžícího v browseru. Tam se jakýkoliv uživatelský vstup validoval ještě před posláním na server, znovu na základě stejných anotací na backendu.

Kromě lepší user experience je hlavně takový přístup bezpečnější, než si validace psát třeba v controlleru a hlavně je konzistentně udržovat.

24
Vývoj / Re:Java: String constants a velikost bajtkódu
« kdy: 18. 12. 2017, 17:59:07 »
Definice proměnné zabírá nějaké místo. Má své místo, její název zabírá nějaké místo a odkazy na ni zabírají nějaké místo (to je jen index co tabulky řetězců).

Podobně, když zorganizuju kód do několika metod, místo, abych splácal všechno do jedné - taky bude ve výsledku větší (v bytecode).

JIT udělá práci za vás a splácá všechno dohromady, takže výsledek bude stejný. Tedy žádný vliv na výkon a malý vliv na paměť (stále bude formálně existovat proměnná daného jména).

25
Server / Re:Apache regex
« kdy: 12. 07. 2017, 00:46:01 »
skupina (\w+) je $1 ?

Kód: [Vybrat]
#RewriteRule .cz/client/(\w+)/  $1.php [NC,QSA]

Mno, skoro. Byla by, kdyby to celé nebylo zakomentované (# na začátku).

26
Server / Re:Out of memory - paměti na serveru je dost
« kdy: 15. 06. 2017, 00:45:39 »
Kernel je buď 64-bit nebo 32-bit z PAE, jinak by nemohl využít těch 64GB, což by pak dávalo jiné čísla v /proc/meminfo

V obou případěch bych zkusil upgrade, pokud to s danou distribucí nějak půjde, správa paměti se postupně zlepšovala. Zvláště v případě, že je tam PAE, které je samo o sobě velká magie se spoustou omezení.

Příčina, proč teď najednou a ne dřív, může být spousta - větší load, větší traffic a rychlejší potřeba alokace paměti, na kterou kernel nestíhá správně reagovat (pomalost uvolňování / zapisování cache / buffers, či jednoduše nějaká chyba - race condition, whatever). 2.6.27 je hodně stará verze, takže upgrade může snadno vyřešit...

27
Hardware / Re:Výkon ARM vs. x86
« kdy: 21. 10. 2016, 21:53:44 »
To platí pouze pro Windows world, kde je většina proměnných WORD či DWORD a maďarština se používá na každém řádku. Pro POSIX, kde lidi používají platform independent typy size_t, off_t, uintptr_t, time_t a další, portace velkých projektů byla většinou opravdu jen o zkompilování a spuštění (namátkou KDE, Emacs, ViM, OpenOffice). Firefox je nejspíš lehce jiný případ pouze kvůli závislosti na 3rd party plugins.
Aha. Tak se koukneme na GLib (základ GTK), Qt a Win32. Kupodivu definují vlastní typy: quint32, guint32, DWORD, ...
https://developer.gnome.org/glib/stable/glib-Basic-Types.html
http://doc.qt.io/qt-4.8/qtglobal.html
https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751(v=vs.85).aspx

To je naprosto v pořádku, že tam ty typy jsou. Jsou místa, kde je třeba mít pevně daný typ, například při serializaci. Problém Windows world a jejich developerů je, že je používají naprosto špatně, i v místech, kde mají použít "logický" typedef (off_t, size_t atd). Například
Kód: [Vybrat]
DWORD WINAPI GetFileSize(_In_      HANDLE  hFile,  _Out_opt_ LPDWORD lpFileSizeHigh);, zatímco POSIX má jednoduše off_t. A chování té funkce je tedy lahůdka, nepoužívám ostrá slova, ale tohle musel designovat opravdu blbec posedlý DWORDy: Note that if the return value is INVALID_FILE_SIZE (0xffffffff), an application must call GetLastError to determine whether the function has succeeded or failed. The reason the function may appear to fail when it has not is that lpFileSizeHigh could be non-NULL or the file size could be 0xffffffff. In this case, GetLastError will return NO_ERROR (0) upon success.

Díky za link na Windows Data Types, to je taky dílo:
Kód: [Vybrat]
DWORDLONG - A 64-bit unsigned integer. The range is 0 through 18446744073709551615 decimal.
DWORD32 - A 32-bit unsigned integer.
DWORD64 - A 64-bit unsigned integer.

DWORD byl původně double word, resp 32-bit uint, což je jako platform independent samo o sobě brain-damaged, ale vem to peklo. Tady z pevně daného typu udělají suffixem jiný typ přesto, že logické jméno reflektuje ten starý pevný 32-bit. To byl jen příklad, v rámci toho linku se dají najít mnoho dalších neméně "povedených"

Qt a Glib oproti tomu mají jasné a výstižné názvy, ze kterých je jasně viditelný smysl, použití a velikost.

28
Hardware / Re:arm vs x86
« kdy: 19. 10. 2016, 16:39:40 »
16-bitový režim dodnes používají embedded systémy, plus spousta historických aplikací typu malých národních účetnictví (za všechny třeba produkty mrp.cz).
http://arstechnica.com/information-technology/2014/07/it-may-be-barely-an-operating-system-but-dos-still-matters-to-some-people/

32-bitový režim je nutný pro podporu 16-bitového kódu, protože ze 64-bitového OS na Intelu 16-bitový kód nepustíte.

mrp.cz má jenom 16-bitové produkty verze??? Jak se teda pustí na většině nových systémů, jak je napsáno v druhém odstavci? Produkt, který by byl dneska 16-bitový, by na trhu neměl naprosto žádnou šanci.

Dále je tu spousta slabého HW s omezenou RAM, kde se 32-bitové OS dodnes používají. Navíc je tu spousta SW, který je k dispozici jen v 32-bitové verzi. Zkuste zákazníkovi vysvětlit, že mu na jeho novém HW nepůjde starší verze Oracle RDBMS, Lotus Domino/Notes, nebo jeho ekonomický systém; klidně na Linuxu. Kdo dělá business, nevystačí s aplikacemi z distra.

Pokud nedáte zákazníkovi zpětnou kompatibilitu, nebo jen budete starý SW běžet pomaleji, budete jen opakovat to co Intel zjistil u platformy IA64: zpětná kompatibilita je zásadní.

Proto jsem psal, že odstranění 32 bitů by si část korporátních zákazníků všimla. Zrovna Oracle ale není úplně dobrý příklad, neboť ten se dá zrovna snadno pustit v 64-bitové variantě a je to pro klienty zcela transparentní. Nehledě na to, že provozovat jakýkoli starý software je bezpečnostní riziko...

IA64 dojel na úplně jiné věci, podporu od relevantních software společností měl dostatečnou (bavíme se o server side), primárním důvodem byla kombinace mizerného výkonu a vysoké ceny. Sice možná mohla porazit (v té době už) dinosaury typu Alpha, PA-RISC a další, ale utopická architektura nakonec podlehla ač zastaralé, tak přesto flexibilní x86_64. Nicméně, i kdyby tomu tak bylo, IA64 byla novinka ve světě x86, zatímco o 15 let později je x86 legacy ostrůvek ve světě x86_64, ARM a dalších.

29
Vývoj / Re:Pametova a vypocetni narocnost JVM vs .NET
« kdy: 16. 09. 2016, 21:36:00 »
Jak už jsem se opravil, měl jsem na mysli absenci uživatelsky def. hodnotových typů + specializace.

Příkladem je seznam čísel, když v Javě použijete generický ArrayList pro uložení 1000 intů. Předpokládejme, že aplikace běží nad HotSpotem a na 64 bitové architektuře. Pro takový seznam se alokuje minimálně 1002 objektů. Každý objekt

Analogická věc v .NET Core zabere zhruba 4032 bajtů + velikost dalších dat ve třídě List. Na rozdíl od Javy, kde se alokovalo 1002 objektů se zde alokují pouze 2 objekty (instance generické třídy List a pole).

Struktury v C# jsou pěkné a občas můžou pomoct, kromě toho, že samozřejmě mají své negativní stránky. Hlavní problém je ale v tom, že jejich využití v nějakých větších blocích či datových strukturách je natolik minoritní, že v zásadě nemají na typickou aplikaci významný vliv. Běžně to bývají spíš hodně low-level věci, které se stejně napíšou externě v low level jazyce C, C++ či dokonce platform specifc (ať už C s nějakýma SSE builtins nebo rovnou assembler) - typicky kryptování, maticové operace atd.

30
Vývoj / Re:Algoritmus pro skládání kousků dřeva
« kdy: 09. 06. 2016, 20:31:44 »
Já to samozřejmě pochopil, že záporná délka neexistuje a není ji proto možné aplikovat, snažil jsem se upozornit na nedostatky v zadání a nutnost pamatovat na takovéto věci v algoritmu, protože počítač neřeší dřívka, ale čísla a pro něj je co největší záporné číslo určitě nejmenší a proto správný výsledek, dle zadání, které není jednoznačné ;-). Dělám často analýzy zadání a tohle se děje běžně. To co je pro jednoho jasné, dává jinému hromadu možností ;-).

Zadání je naprosto v pořádku. Pokud zákazníkovi běžně tvrdíte, že skřín měří 50cm a z druhého konce -50cm, bude problém někde jinde [než u zákazníka].

Stran: 1 [2] 3 4

reklama