Até encontrar esta situação, todos os casos com que me tinha deparado eram sempre causados por uma colecção static que não estava a ser devidamente mantida. Esta situação, é ligeiramente diferente, no sentido em que a colecção em causa não é mantida directamente pela aplicação, mas sim pelo SWT. É um problema conhecido como “Lapsed Listeners” e está bem descrito aqui:

http://www.javaworld.com/javaworld/javatips/jw-javatip79.html?page=1

Resumidamente: lembrem-se sempre de remover os listeners que já não são acessíveis, ou então implementem-nos com uma WeakReference.

Partilhar

Basicamente queria que em vez de ser invocado o executável que lança a JVM fosse primeiro chamado um shell script para fazer umas validações antes de chamar o executável. Pareceu-me que a forma correcta de o fazer seria editar o ficheiro:

Info.plist

dentro do application bundle, nomeadamente a propriedade:

CFBundleExecutable

que como o próprio nome sugere, indica qual é o executável que deve ser lançado quando o utilizador faz duplo-clique na aplicação em causa.

Infelizmente, por muito que alterasse a bendita propriedade, nada. O sistema continuava tranquilamente a invocar o executável. Aparentemente a alteração estava a ser ignorada por algum motivo.

Não foi fácil de encontrar, mas já alguém tinha tentado fazer o mesmo e obtido o mesmo resultado:

Hi,
I’m trying to customize the behavior of certain application bundles by editing the Info.plist preferences. The idea is to change the CFBundleExecutable key to point to a different file. Unfortunately, my changes seem to be ignored. — by Chadrik in Apple Support Forums

E felizmente alguém tinha respondido:

Some of those things are only read at startup or logiin, hence no change will happen until you logout or restart. — by BDAquain Apple Support Forums

Enfim, só foi pena as horas perdidas… as caches são umas gajas lixadas… sobretudo quando não se sabe que elas existem

Mas ainda assim, não há quem me convença que a coisa está mal feita… seria assim tão difícil ao leopardo, no momento em que guarda o ficheirito em cache registar-se na FAM (ou no kqueue que parece ser a alternativa em Mac / BSD…) para receber notificações de alteração?

Partilhar

O que é se faz a uma coisa destas? A solução parece óbvia: “alteras o método instance() para devolver sempre um objecto novo”, efectivamente desfazendo o comportamento de singleton. Ok, funciona, mas e se o impacto em termos de performance for demasiado elevado? O que fazer quando se pretende manter o comportamento de singleton, mas ao nível do Thread, em vez de ser ao nível da JVM?

A resposta é substituir as variáveis existentes que guardam informação de estado por outras do tipo ThreadLocal<T>.

This class provides thread-local variables. These variables differ from their normal counterparts in that each thread that accesses one (via its get or set method) has its own, independently initialized copy of the variable. ThreadLocal instances are typically private static fields in classes that wish to associate state with a thread (e.g., a user ID or Transaction ID).

Ok, perfeito, não é?

Hmm… quase. Funciona bem se a criação dos threads for feita exclusivamente “antes” da primeira utilização da classe. Dessa forma cada thread inicializa a sua própria cópia uma só vez e trabalha com ela daí para a frente.

Mas e se forem necessários vários níveis de multi-threading, alguns dos quais “depois” da primeira utilização da classe? De acordo com a forma de funcionamento das variáveis ThreadLocal, cada thread filho teria uma instância nova, o que pode corresponder a esforço desnecessário e, dependendo dos casos, ter um impacto significativo no desempenho.

O nome diz tudo:  InheritableThreadLocal<T> é uma subclasse de ThreadLocal<T> que permite herdar a instância do thread pai se ela existir.

 This class extends ThreadLocal to provide inheritance of values from parent thread to child thread: when a child thread is created, the child receives initial values for all inheritable thread-local variables for which the parent has values. Normally the child’s values will be identical to the parent’s; however, the child’s value can be made an arbitrary function of the parent’s by overriding the childValue method in this class.

Agora sim, perfeito.

Partilhar

Com uma descrição destas a primeira coisa que me ocorre é DNS. Como a aplicação não deixa de funcionar, fica simplesmente mais lenta, provavelmente o problema estará numa resolução inversa de DNS, que são frequentemente feitas pelas aplicações / middleware apenas para efeitos de logging.

Para não restarem dúvidas que o problema se relacionava com DNS, o servidor em causa tinha a configuração de DNS a apontar para o servidores do ISP, que obviamente ficam inacessíveis cada vez que se perde o acesso à Internet.

Comecei por procurar na aplicação, mas não encontrei nada que justificasse um lookup inverso de DNS. No tomcat encontrei um parâmetro que parecia promissor:

enableLookups - Set to true if you want calls to request.getRemoteHost() to perform DNS lookups in order to return the actual host name of the remote client. Set to false to skip the DNS lookup and return the IP address in String form instead (thereby improving performance). By default, DNS lookups are enabled.

Mas mesmo depois de desactivar o problema persistia. Descendo ainda mais na stack aplicacional descobri este bug no Java, já antiguinho, mas ainda aplicável à versão que estava a ser usada:

There is a call to InetSocketAddress.getHostName() in the ProxySelector code. This will trigger a reverse lookup when the hostname is not already known. If DNS is not configured correctly on the machine, this will generate a long timeout.

Foi este post na mailling list do Postgres que me conduziu ao bug em si e a descrição que fazem do problema é mais fácil de entender (e mais assustadora):

I can confirm that this is an issue in JDK 1.5 (a/k/a Java5) in Windows.  This is not the fault of postgres, but like others have suggested, it is with reverse DNS lookup.  It affects all TCP connections.
If you connect to an IP address it attempts to look up the name, resulting in these delays.

Se actualizar a versão de Java não for uma hipótese viável (como não era no meu caso), e se a resolução inversa ocorrer sempre para o mesmo endereço IP ou conjunto restrito de endereços, a solução pode ser mesmo adicioná-los ao ficheiro de hosts (C:\windows\system32\drivers\etc\hosts ou /etc/hosts).

Pelo caminho ainda descobri uma forma fácil de ver o conteúdo da cache de DNS num sistema windows:

ipconfig /displaydns

Se ficaram curiosos sobre como fazer a mesma coisa em Linux, a resposta não é fácil. Sem software adicional o kernel Linux não inclui uma cache de DNS, cada pedido é um pedido. Existe o nscd (Name Server Cache Daemon) que é bastante comum mas não vem pré-instalado em todas as distribuições (por exemplo não vinha no último Debian que instalei).

Partilhar

A primeira opção é a escolha típica numa aplicação stand-alone, mas a opção de utilizar uma datasource JNDI é a que faz mais sentido para application servers. Portanto, o ficheiro de configuração do Hibernate há-de ter, parcialmente, este aspecto:

<hibernate-configuration>
<session-factory>
<property name="hibernate.connection.datasource">
java:my_app_name
</property>
<property name="hibernate.setup">true</property>
<property name="hibernate.dialect">
org.hibernate.dialect.MySQLInnoDBDialect
</property>
<property name="transaction.factory_class">
org.hibernate.transaction.JDBCTransactionFactory
</property>
<property name="current_session_context_class">
thread
</property>
</session-factory>
</hibernate-configuration>

Depois basta definir a datasource com o nome JNDI correspondente, por exemplo assim:

<datasources>
<local-tx-datasource>
<jndi-name>my_app_name</jndi-name>
<connection-url>jdbc:mysql://host_or_ip/db_name</connection-url>
<driver-class>com.mysql.jdbc.Driver</driver-class>
<user-name>username</user-name>
<password>password</password>
<min-pool-size>5</min-pool-size>
<max-pool-size>20</max-pool-size>
</local-tx-datasource>
</datasources>

Agora que está tudo montado como manda a documentação, sugiro uma experiência:

1. Ligar servidor BD.
2. Ligar application server.
3. Testar aplicação que se liga à base de dados (funciona)
4. Reiniciar servidor BD (ou esperar 8 horas).
5. Testar aplicação que se liga à base de dados (não funciona!)

Então… tanto trabalho para abstrair a ligação a base de dados e um simples restart da base de dados deixa as ligações geridas pelo Hibernate todas inválidas? E, pior, não há recuperação automática?

Pois… parece que não. E acrescentar o parâmetro autoReconnect=true ao URL JDBC também não resolve, aliás, a utilização desse parâmetro até é desaconselhada, como se pode ver pelo que diz no manual:

Should the driver try to re-establish stale and/or dead connections? If enabled the driver will throw an exception for a queries issued on a stale or dead connection, which belong to the current transaction, but will attempt reconnect before the next query issued on the connection in a new transaction. The use of this feature is not recommended, because it has side effects related to session state and data consistency when applications don’t handle SQLExceptions properly, and is only designed to be used when you are unable to configure your application to handle SQLExceptions resulting from dead and stale connections properly. — MySQL 5.0 Reference Manual

A solução que encontrei para MySQL (e que também funciona para MS SQL Server), é acrescentar a seguinte linha ao ficheiro de configuração da datasource:

<check-valid-connection-sql>SELECT 1</check-valid-connection-sql>

Esta opção faz mesmo aquilo que parece fazer, ou seja, antes de usar uma ligação, a query ali especificada é executada como forma de verificar se a ligação é usável. Se não ocorrer nenhum erro, a instrução SQL que realmente se pretende executar é enviada pela mesma ligação, se houver um erro, a ligação é descartada e é criada uma nova.

Claro que isto tem um impacto sério na performance uma vez que se está a duplicar o número de queries, o que pode ser particularmente grave se o acesso à base de dados for feito através de um canal de elevada latência (rede, por exemplo).

Aparentemente existem soluções melhores para outras bases de dados, como o seguinte comentário parece sugerir:

Whilst you can use the old “select 1 from dual” trick, the downside with this is that it issues an extra query each and every time you borrow a connection from the pool. For high volumes, this is wasteful.

JBoss provides a special connection validator which should be used for Oracle:

org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker

This makes use of the proprietary ping() method on the Oracle JDBC Connection class, and uses the driver’s underlying networking code to determine if the connection is still alive. — stackoverflow.com

Alguém conhece uma alternativa semelhante para MySQL?

Partilhar

Resumidamente, quando o pedaço de código do eclipse que é nativo de cada plataforma consegue iniciar uma JVM por JNI, temos um único processo, quando não consegue usa os executáveis do JRE em causa, o que resulta num novo processo. Uma forma de forçar a invocação por JNI e, consequentemente, a existência de um único processo, é especificar a opção “-vm” na linha de comando ou no ficheiro eclipse.ini  e apontá-la directamente para o ficheiro jvm.dll (ou libjvm.so) do JRE em causa. Isto pode ser particularmente importante quando se tem que parar programaticamente o eclipse em plataformas que não sabem muito bem gerir a hierarquia entre processos (leia-se: Windows): 

The fundamental problem here is that, unlike Unix, Windows does that maintain parent-child relationships between processes. A process can kill its own immediate children, but unless you make other arrangements to obtain the information, can’t kill any ’grand-children’ because it has no way of finding them. Ctrl-C types at a command prompt is just a character that the command processor interprets and not a signal sent from outside. When you ‘destroy’ a child command script, that process does not get the opportunity to terminate any child processes it may know about. Recent versions of WIndows (2000 or later) do provide a “Job” concept which acts as a container for processes. Killing a Job does terminate all processes associated with that job. However Jobs do not contain other jobs, so fully emulating the Unix behaviour is probably impossible. [Sun Bug ID: 4770092]      

Partilhar

Partilhar

Uma das novidades é o novo sistema de actualizações de plugins e features, o P2. Vale a pena ler este artigo, sobretudo para quem desenvolve plugins para o dito.

Partilhar

Essa herança tem uma consequência interessante: as letras do alfabeto não têm todas códigos consecutivos. Existe um intervalo entre a letra ‘I’ e a letra ‘J’, por exemplo. Outra característica interessante é que os códigos correspondentes aos dígitos 0-9 são maiores do que os códigos de todas as letras do alfabeto, enquanto que em ASCII acontece o oposto. Também os sinais de pontuação aparecem em posições relativas diferentes, assim como os caracteres acentuados.

Para referência, aqui ficam links para as duas tabelas: EBCDIC (codepage 037) e ASCII.

Em EBCDIC, a sequência efectiva de caracteres de acordo com o seu código numérico é a seguinte:

 âäàáãåçñ¢.<(+|&éêëèíîïìß!$*);¬-/ÂÄÀÁÃÅÇѦ,%_>?øÉÊËÈÍÎÏÌ`:# \

@’=”Øabcdefghi«»ðýþ±°jklmnopqrªºæ¸Æ€µ~stuvwxyz¡¿ÐÝÞ®^£ \

¥·©§¶¼½¾[]¯¨´×{ABCDEFGHI­ôöòóõ}JKLMNOPQR¹ûüùúÿ\÷S \

TUVWXYZ²ÔÖÒÓÕ0123456789³ÛÜÙÚŸ

Interessante, não? Os caracteres acentuados aparecem nos “intervalos”da tabela original…

Mas de facto, do ponto de vista prático, a consequência mais importante desta diferença é a seguinte: Uma aplicação baseada, por exemplo, em AS/400 apresenta uma listagem ordenada de forma diferente de uma aplicação escrita em Java. Em ambientes de migração esta diferença pode ter consequências drásticas para utilizadores que, por exemplo, tiram partido de o underscore aparecer antes das letras do alfabeto, para dessa forma criarem elementos que aparecem sempre à cabeça de uma lista.

Uma forma de, para o bem ou para o mal, passar a ordenar Strings de acordo com a tabela EBCDIC é implementar um Comparator que use um RuleBasedCollator criado especificamente com a sequência de caracteres EBCDIC.

Por exemplo assim:


String ebcdic_rules = "< â < à < á < ã < ç < ñ < '.' < '<' < '(' < '+' < '|' < '&' < é < ê < è < í < î < ì < '!' < '$' < '*' < ')' < ';' < '-' < '/' < Â < À < Á < Ã < Ç < Ñ < ',' < '%' < '_' < '>' < '?' < É < Ê < È < Í < Î < Ì < '`' < ':' < '#' < '@' < ''' < '=' < '\"' < a < b < c < d < e < f < g < h < i < '«' < '»' < j < k < l < m < n < o < p < q < r < ª < º < '€' < '~' < s < t < u < v < w < x < y < z < '^' < '£' < '[' < ']' < '´' < '{' < A < B < C < D < E < F < G < H < I < ô < ò < ó < õ < '}' < J < K < L < M < N < O < P < Q < R < û < ù < ú < '\\' < S < T < U < V < W < X < Y < Z < Ô < Ò < Ó < Õ < 0 < 1 < 2 < 3 < 4 < 5 < 6 < 7 < 8 < 9 < Û < Ù < Ú";

Collator collator = new RuleBasedCollator(ebcdic_rules);

if(collator.compare(a, b) < 0){
    //a is less than b according to EBCDIC sorting criteria
} else {
    //a is equal or greater than b
}

Partilhar

As funcionalidades que este visualizador deve disponibilizar são extremamente simples:

1. Quando aberto pela 1ª vez deve mostrar a 1ª página do documento.
2. Deve disponibilizar um botão para avançar uma página.
3. Deve disponibilizar um botão para retroceder uma página, se não se encontrar já na 1ª página.

Para além disto, há um requisito não-funcional a ter em conta:

• Deve ser possível e eficiente visualizar e navegar num ficheiro com dimensão muito superior à memória disponível para o processo.

Se tivessem que implementar uma coisa destas em Java, e esquecendo por completo a componente gráfica, que classes do JDK usariam para ler o ficheiro?

A resposta mais imediata é provavelmente uma conjugação de um BufferedReader  com um qualquer tipo de InputStream. Partindo desta ideia, implementar a funcionalidade 2 é muito simples, mas como fazer para implementar a 3? Acumular as páginas que já se avançou em memória não é razoável, porque esbarra no requisito não-funcional. Voltar ao início do documento e avançar n-1 páginas também não, pelo mesmo motivo. O que fazer se não é possível navegar “para trás” num InputStream?

Há uma classe que parece ser a solução, mas de facto não é. O PushBackInputStream permite fazer unread() de bytes lidos de um InputStream, mas guarda-os num buffer em memória, por isso não é viável.

A solução que encontrei está numa classe que já vem do JDK 1.0: RandomAccessFile. Esta classe disponibiliza um método seek() para posicionar em qualquer ponto do ficheiro, e os habituais métodos read() e readLine().

Há apenas dois problemas com esta abordagem:

• Deveria ser possível especificar o encoding que se pretende usar ao manipular um ficheiro, por exemplo no construtor da classe, ou em última análise como parâmetro dos métodos de leitura/escrita. Tal não é possível, o que significa que é necessário garantir que os ficheiros se encontram no encoding do sistema, ou alternativamente alterar o encoding do sistema para que corresponda ao do ficheiro. O método readUTF() poderia resolver este problema, não fosse a limitação de obrigar a ler o ficheiro todo de uma só vez.
• O método seek() só aceita como parâmetro o offset em bytes desde o início do ficheiro. Seria útil, para além de poder especificar um offset relativo à posição actual, especificar um offset por exemplo em número de linhas (embora do ponto de vista de implementação isso tivesse que ser feito de forma radicalmente diferente de um seek() normal).

Alguém tem sugestões de implementação melhores? Agradeciam-se…

Partilhar