Uncategorized

Trying to install an already registered mbean.

Posted in Uncategorized on February 22nd, 2011 by admin – 2 Comments

Another JAVA error here, another simple resolution. In this case two of our JAVA developers were trying to deploy compiled code to run withing JBoss, however were seeing the following error.

ERROR [org.jboss.deployment.MainDeployer] Could not create deployment:
file:/usr/local/EnterprisePlatform-4.3.0.GA/jboss-as/server/production/deploy/epjndi-ds.xml

org.jboss.deployment.DeploymentException:
Trying to install an already registered mbean: jboss.jca:service=LocalTxCM,name=jdbc/epjndi

The error lead us to believe (obviously) that we had two configurations conflicting with one another and this was the case. This was easily found by searching the root path of our JBoss deployment, via…

find . | xargs grep 'epjndi'

The return:

./apps/storefront/WEB-INF/epjndi-ds.xml:  <jndi-name>jdbc/epjndi</jndi-name>
./epjndi-ds.xml:  <jndi-name>jdbc/epjndi</jndi-name>

We moved the epjndi-ds.xml from WEB-INF and walla, issue resolved, hope this helps anyone seeing this issue :)

Problem in init java.io.EOFException: Unexpected end of ZLIB input stream

Posted in Uncategorized on February 22nd, 2011 by admin – Be the first to comment

Just spent an hour or so working with several JAVA developers trying to resolve this issue.

Our sever log was showing errors consistent with the following:

ERROR [URLDeploymentScanner] Incomplete Deployment listing
Problem in init java.io.EOFException: Unexpected end of ZLIB input stream

Initially believing this issue is caused by our deployed JAVA code, however after some tinkering on my end it was determined the issue is related to JBoss tmp/work files, so if you come across this issue it can be solved by delete (or preferably moving) any files contained withing the tmp and work directories contained withing the JBoss directory/deployment.

Cannot assign requested address errors.

Posted in Uncategorized on February 22nd, 2011 by admin – Be the first to comment

Recently spent sometime working on a few RHEL/CentOS servers, after a reboot each system would come up in an unresponsive state, after some KVM sessions something was preventing these systems from statically assigning their respective IP addresses as per the config(s), the logs indicated the following problem.

SIOCSIFBROADCAST: Cannot assign requested address SIOCSIFBRDADDR: Cannot assign requested address SIOCSIFFLAGS: Cannot assign requested address

I’ve ran into this error a couple of times and each time the problem was different as was the resolution. Luckily the problem was quickly identifiable, having dug through ‘ps’ a bit, I noticed the wpa_supplicant daemon running which is essentially a wireless component of the NetworkManager package, these are all packages you’ll typically find on a desktop system. It appeared as though these packages were essentially holding our static IP address hostage and not allowing us to bind it to our interface (eth0). Luckily solving this problem was quick and easy.

via YUM: First let’s check to see if it’s installed.

yum list | grep wpa_supplicant

via YUM: remove wpa_supplicant (Will also remove NetworkManager package).

yum remove wpa_supplicant

via RPM: First let’s check to see if it’s installed.

rpm -qi wpa_supplicant

via RPM: remove wpa_supplicant

rpm -e wpa_supplicant

Now try to bringup your interface.

ifup eth#