AdamWozniak

I am prefectionist!

Moje zdjęcie
Piaseczno, mazowieckie, Poland

środa, 3 sierpnia 2011

Problem z dyskiem sieciowym Seagate BlackArmor NAS 110 i ruterem TP-Link

Wiele osób zgłasza w sieci problem z podłączeniem dysków sieciowych Seagate BlackArmor NAS (ja posiadam najmniejszy z nich: NAS 110) do swoich sieci domowych.
Kiedy mój NAS 110 był podłączony do innego rutera (LinkSys) wszystko działało bez zarzutu. Niestety musiałem zmienić ruter i kupiłem ruter TP-Link. Po podłączeniu dysku NAS 110 do rutera TP-Link dysk NAS nie jest widoczny zarówno przez oprogramowanie dołączone przez producenta dysku (oprogramowanie Discovery) jak i mój odtwarzacz Blu-Ray, który potrafi czytać dane z dysków DLNA (dysk NAS melduje się w sieci jako dysk DLNA).
Oddałem dysk na gwarancji będąc przekonany, że padł mi dysk. Dostałem nowy dysk NAS 110. Niestety i ten nowy dysk wciąż nie był widoczny w mojej sieci domowej (zarządzanej przez ruter TP-Link).
Podłączyłem dysk NAS i komputer do innego rutera (LinkSys) i ze zdziwieniem zobaczyłem, że dysk poprawnie jest rozpoznawany przez oprogramowanie Discovery!
Korzystając z okazji, że dysk jest widoczny i mogę wejść za pośrednictwem przeglądarki internetowej w ustawienia dysku NAS (interfejs WWW) przestawiłem dynamiczne przyznawanie adresu IP na ustalony statyczny adres IP.
Po podłączeniu tak skonfigurowanego dysku ponownie do mojej sieci z ruterem TP-Link dysk ten zaczął być poprawnie widoczny i poprawnie wykrywany przez oprogramowanie Discovery.

Straciłem na to niestety masę czasu :(

Inne miejsca, gdzie internauci opisują ten problem (na tych stronach nikt niestety nie znalazł rozwiązania tych problemów):
1. http://www.amazon.com/review/R3TMH2BWEKXZCD/ref=cm_cr_dp_cmt?ie=UTF8&ASIN=B002HKCVVW&nodeID=172282&tag=&linkCode=#wasThisHelpful

2. http://forum.pclab.pl/topic/693046-Seagate-BlackArmor-router-ZTE-neostrada/

czwartek, 11 grudnia 2008

Select language...


Pomysł: Emil EPE P.
Wykonanie: Adam AWO W. (Microsoft Paint 6.0)

czwartek, 10 lipca 2008

zagadka algorytmiczna

W sumie znam jedną zagadkę algorytmiczną ;> Za to bardzo ją lubię (i pewnie dla tego ją pamiętam):

Generalnie pytanie brzmi: jak używać niezainicjalizowanej tablicy?

Zakładamy, że alokacja bloku pamięci wykonuje się w czasie stałym, czyli O(1) i czas alokacji pojedynczego bloku nie jest zależy od wielkości bloku pamięci.

Zadanie:
Znajdź algorytm, który pozwoli korzystać z niezainicjalizowanej tablicy.
Tworzenie tej tablicy ma się odbywać w czasie STAŁYM (czyli nie możemy sobie pozwolić na np. wyzerowanie jej wszystkich elementów; tablica - po zaalokowaniu - wypełniona jest śmieciami).
Dostęp (odczyt / zapis) do i-tego elementu ma się odbywać w czasie O(1), czyli tak jak w normalnej tablicy.
Naturalnie można korzystać z pomocniczych struktur ;)
Można założyć, że operacja odczytu i-tego elementu, który wcześniej nie był zapisywany, ma zwracać 0.

(koniec zagadki)

I żeby rozwiać wszelkie wątpliwości jeszcze mój komentarz:
Dla "normalnych" tablic, mamy tak (n - ilość elementów):
złożoność pamięciowa: O(n)
złożoność czasowa tworzenia i inicjalizacji tablicy: O(n)
operacja odczytu i-tego elementu: O(1)
operacja zapisu i-tego elementu: O(1)

Celem zagadki, jest znalezienie struktury danych, o takich samych charakterystykach, z tą różnicą, że czas tworzenia (i ewentualnej inicjalizacji) ma być: O(1).

Bez straty ogólności można założyć, że w tablicy mamy liczby typu int.

wtorek, 17 czerwca 2008

Hibernate: to obtain fetch_size / batch_size / default_batch_fetch_size / etc. programmatically

The question is:
How to obtain (during runtime) fetch_size / batch_size / default_batch_fetch_size / etc. programmatically when the only thing I have is a reference to EntityManagerFactory?

Here is my proposition:
EntityManagerFactory mainEmf = ...;
(...)
final HibernateEntityManagerFactory hibernateEntityManagerFactory = (HibernateEntityManagerFactory) mainEmf;
final SessionFactory sessionFactory = hibernateEntityManagerFactory.getSessionFactory();
SessionFactoryImplementor sessionFactoryImplementor = (SessionFactoryImplementor) sessionFactory;
final Settings settings = sessionFactoryImplementor.getSettings();

final int jdbcBatchSize = settings.getJdbcBatchSize();
final int jdbcFetchSize = settings.getJdbcFetchSize();
final int defaultBatchFetchSize = settings.getDefaultBatchFetchSize();



Why, the hell, I want to have those values?
Well... There is at least one reason :)

In the Hibernate documentation, we can find a piece of code (13.1. Batch inserts):
for ( int i=0; i<100000; i++ ) {
Customer customer = new Customer(.....);
session.save(customer);
if ( i %
20 == 0 ) { //20, same as the JDBC batch size
//flush a batch of inserts and release memory:
session.flush();
session.clear();
}
}
As we can see, in this example it is good to know the size of predefined value for JDBC batch size (defined in hibernate.cfg.xml file). For performance reasons those values (in the hibernate.cfg.xml fiel and in our Java sources) should be equal.
This trick avoids me to change Java source code when I'm going to change my JDBC batch size (such situation is quite usual when trying to find optimal setting for JDBC batch size).

Well... I don't think that this trick is a simplest way to get those values programmatically. If someone has better solution - give a piece of code as a comment :)

Regards,
Adam