I was asked this question in a forum and have not been able to find an answer to it so far. The Question is "What is the coding principle/practices to follow which would aid in high availability of your application."
I have always thought that High Availability can be achieved by clustering or following other Operational practices while deployment to ensure that the application is available 99.99%. I have done my bit of online research and have not been able to find a convincing answer which would point me to some practices that would help make the application more available.
Requesting you folks to throw some light on the topic and see what could be done while developing/writing code which would benefit in the form on Hight Application Availability.
i finally managed to fix the issue and following is what we did:
Added the below given snippet to the mysql-ds.xml file which does a background check on the connection pool and ensures that there are no stale connection objects in the pool. Apparently, it was the stale connection objects which caused the issue.
I am getting the "User null is NOT authenticated" exception in JBoss after migrating from HSQLDB to Mysql for JBoss Messaging.
JBoss Server 5.1 (4 node cluster)
Heres what i did to migrate from HSQLDB to Mysql:
1. Copied the Mysql JDBC driver (mysql-connector-java-184.108.40.206-bin) to the lib folder of the nodes in JBoss.
2. Replacde the file hsqldb-ds.xml with mysql-ds.xml in the deploy folder in JBoss.
3. Replaced the file hsqldb-persistence-service.xml with mysqldb-persistence-service.xml in the messaging folder under deploy in JBoss.
4. Updated the file mysql-ds.xml to have the following:
5. Uncommented the "guest=guest" entry in the messaging-users file.
6. Added the following in the login-config file present in jboss/conf folder:
7. Added a reference to the MySqlDbRealm in the mysql-ds file by adding the following:
8. Ensured that the <type-mapping>mySQL</type-mapping> property vale present in mysql-ds.xml file is the same as the <type-mapping> property in standardjbosscmp-jdbc.xml file.
I am guessing, i am missing some configuration which is causing the issue. Could someone educate me on what needs to be updated to fix this issue. I see a few people have the same issue, but was not able to find a concrete solution or a pointer to the root cause of the issue.
We have our application deployed on JBoss 5.1.1 and we use Mysql 5.1 for messaging persistance in JBoss (we recently moved from using the default Hypersonic DB to Mysql). We see the following exception every time we restart JBoss while we run a test.
Can some one please help me figure out why this could occur? I can see that its related to the way the messages are persisted in the persistant store which is Mysql in this case, but dont understand why this occurs.
I am new to the keystore concept and hence my question could be quite silly.
I have created a new keystore and have added the private and public key certificates into the keystore using the keytool commands and also got my test application to work fine using the keystore. Now, when i ran the test class from my IDE, i figured that the keystore has to be in the application's class path for it to work fine.
My question is: when i deploy my code to the server, should i add the keystore file location to class path so that the application works fine or is it not required?
I used mobicents to create a client and server class to send diameter request and get a diameter response back, how do we package this as a deployable app (may be a SAR) and reference it inside another application. Is it possible to deploy the same inside an ear file?
I am new to JDiameter which is a Java Implementation of the Diameter (AAA) protocol, i need help in writing a simple application which sends and receives Diameter messages. I have not been able to find resources to support the JDiameter issues/questions thus far and request help in directing me to any resources available or any one who has worked on the same to help me answer some questions on the implementation.
May be i wasnt clear enough...we tried the normal VTD API for a file which was 600MB size and it seemed to work fine, since the VTD HUGE parser was meant for files bigger than 2 GB - we tried a file which was 3GB and it did not work fine. We even tried a smaller file (500 MB) with VTD Huge and it did not seem to work fine. The code was updated correctly for the VTD HUGE parser and also the Jars required for VTD HUGE were included in the classpath, may be i am missing something which iam unable to figure out as yet..
But the question was : If there was a known issue with VTD Huge parser atall as some forums hinted the same....
we came across the VTD XML Parser which seems to be very cool to parse XML files and we decided to use the VTD-XML Huge API to parse an xml file which is 3GB in size. we followed the documentation given in the below link
For some reason the VTD Huge API seems to fail while parsing and doesnt seem to be able to complete parsing the file, we were told that there could be some problem with the API as it was still in beta version. If there is anyone who was in fact able to use the API for parsing huge xml files, could you please let me know in case of any known tweaks or issues.