Latest Entries »

Hi there,
This blog entry is to make you comfortable working with Drizzle’s RabbitMQ plugin. I will also demonstrate how this can be used dynamically.

RabbitMQ is a message broker. It is like a postoffice which accepts and forwards the messages to different queues. There may be applications built over these queues which receive the messages and process them.

RabbitMQ plugin registers few system variable with drizzle client, namely,

  • logging_enable: This shows if logging function is enabled or not. If disabled, messages will not be forwarded to rabbitMQ server.
  • host: Specifies the host name for rabbitMQ server. IP address of server can also be provided.
  • port: Port on which rabbitMQ is running. Default port is 5672
  • username and password: Logging credentials required for access to rabbitMQ server
  • virtualhost: This specifies the virtual host in which the client intend to operate. (I am not very sure about this.).
  • exchange: This specifies the name of the rabbitMQ exchange. No message is directly pushed to the desired queue. Instead, they are redirected to exchanges. It is the job of exchanges to decide which queue it wants to push the message into.
  • routingkey: This is the name of the queue to which we wants to push the message into.

Plugin in Action
First make sure that rabbitmq server and corresponding libraries are installed on your system. Refer here for more details. Now you will have to rebuild drizzle to build rabbitmq plugin. Start drizzle server with rabbitmq plugin loaded.

ansh@ubuntu:~/repos/drizzle/rabbitmq_dynamic$ drizzled/drizzled –plugin-add=rabbitmq

Now we will start drizzle and check the corresponding variables registered.

ansh@ubuntu:~$ drizzle –user ansh
Welcome to the Drizzle client.. Commands end with ; or \g.
Your Drizzle connection id is 2
Connection protocol: mysql
Server version: Source distribution (rabbitmq_dynamic)Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer.drizzle> SHOW VARIABLES LIKE “%rabbitmq%”;
| Variable_name | Value |
| rabbitmq_exchange | ReplicationExchange |
| rabbitmq_host | localhost |
| rabbitmq_logging_enable | ON |
| rabbitmq_password | guest |
| rabbitmq_port | 371725864 |
| rabbitmq_routingkey | ReplicationRoutingKey |
| rabbitmq_username | guest |
| rabbitmq_virtualhost | / |
8 rows in set (0.001047 sec)

These all are the default variables for the rabbitMQ plugin. We can also pass the desired values when starting the server.

ansh@ubuntu:~/repos/drizzle/rabbitmq_dynamic$ drizzled/drizzled –plugin-add=rabbitmq –rabbitmq.port=5672 –rabbitmq.routingkey=ReplicationRoutingKey –rabbitmq.username=”guest” –rabbitmq.password=”guest”

Now lets try changing some variable to new value. Lets change the name of exchange to “MyOwnExchange”

drizzle> SET GLOBAL rabbitmq_exchange=”MyOwnExchange”;
ERROR 1210 (HY000): Incorrect arguments to SET

Whoa! What is this error? The variable value is perfectly valid. Well, on going to the server console, you will figure out the error.

Value of rabbitmq_exchange cannot be changed as rabbitmq plugin is enabled. You need to disable the plugin first.

Value of variables cannot be changed when plugin is loaded. So, as the plugin suggests, lets stop the plugin first and then change the value.

drizzle> SET GLOBAL rabbitmq_logging_enable=false;
Query OK, 0 rows affected (0.001198 sec)drizzle> SET GLOBAL rabbitmq_exchange=”MyOwnExchange”;
Query OK, 0 rows affected (0.000236 sec)

drizzle> SHOW VARIABLES LIKE “%rabbitmq%”;
| Variable_name | Value |
| rabbitmq_exchange | MyOwnExchange |
| rabbitmq_host | localhost |
| rabbitmq_logging_enable | OFF |
| rabbitmq_password | guest |
| rabbitmq_port | 371725864 |
| rabbitmq_routingkey | ReplicationRoutingKey |
| rabbitmq_username | guest |
| rabbitmq_virtualhost | / |
8 rows in set (0.00106 sec)
drizzle> SET GLOBAL rabbitmq_logging_enable=true;
Query OK, 0 rows affected (0.003609 sec)

No error! 🙂

This is all from database point of view. But how to be sure, if messages are sent to rabbitMQ server or not? In the rabbitmq c library, there are few codes in /examples/ which can be used for this purpose. Open a separate terminal, go to the examples folder of c library and type

ansh@ubuntu:~/Desktop/rabbitmq/rabbitmq-c/examples$ ./amqp_listen localhost 5672 MyOwnExchange ReplicationRoutingKey

This program will now listen for all the messages sent to rabbitMq server’s MyOwnExchange. Now lets query something and check if it actually works.

drizzle> INSERT INTO drizzleslap.t1(intcol1, charcol1) VALUES(123456, “Test Entry”);
Query OK, 1 row affected (0.121521 sec)

On the listener terminal..

ansh@ubuntu:~/Desktop/rabbitmq/rabbitmq-c/examples$ ./amqp_listen localhost 5672 MyOwnExchange ReplicationRoutingKey
Result 0
Frame type 1, channel 1
Delivery 1, exchange MyOwnExchange routingkey ReplicationRoutingKey
00000000: 0A 18 08 01 10 83 BE 04 : 18 9D CC E7 B9 A4 D5 B1 …………….
00000010: 02 20 F6 C7 EB B9 A4 D5 : B1 02 12 72 08 01 10 A6 . ………r….
00000020: CC E7 B9 A4 D5 B1 02 18 : D7 CC E7 B9 A4 D5 B1 02 …………….
00000030: 2A 36 0A 11 0A 0B 64 72 : 69 7A 7A 6C 65 73 6C 61 *6….drizzlesla
00000040: 70 12 02 74 31 12 06 08 : 05 12 02 69 64 12 0B 08 p..t1……id…
00000050: 04 12 07 69 6E 74 63 6F : 6C 31 12 0C 08 01 12 08 …intcol1……
00000060: 63 68 61 72 63 6F 6C 31 : 32 24 08 01 10 01 1A 1E charcol12$……
00000070: 0A 02 37 31 0A 06 31 32 : 33 34 35 36 0A 0A 54 65 ..71..123456..Te
00000080: 73 74 20 45 6E 74 72 79 : 10 00 10 00 10 00 20 01 st Entry…… .
00000090: 28 01 : (.

So, this actually works. 🙂

Similar is the case with other variables. I could have demonstrated them as well, but it required creating new settings in rabbitMQ server (like creating new user, vhosts and setting the permissions etc), which may be a bit confusing. You can get back to me if in case you need that to be demonstrated as well.


Report 3

Last week passed faster than I expected it to. During the week I worked on two separate plugins, namely, auth_http and logging_gearman. Although, according to the order as decided earlier, the turn was for filtered_replicator plugin, but that plugin is temporarily disabled as it depended on transaction_log plugin which has been removed from the system. So working of filtered_replicator will require to solve some dependencies and making all the test cases work. The next in the list was memcached_stats which too has been disabled due to some unknown issues (will update on this soon). Buffering both these plugins for future, I jumped onto auth_http and then logging_gearman.


This is an authentication plugin, which uses apache mod_auth module for authentication. Hence a web server is required for this authentication. This plugin just registers a system variable ‘URL’ with the drizzle server. Making this dynamic just required to make this variable dynamic, so that user can change this at runtime. The work was very simple as there were no cache values and other issues to deal with as in case of other plugins. It just checks if the new url value given is valid or not. It if is then replace the value of the variable with the new one.


This is a logging plugin which uses gearman server to log all the queries submitted to the server. Refer to the previous blog entry for detailed description.

Code References

Dynamic code for regex_policy and auth_file plugins were also merged to the trunk during the last week.
Cheers. 🙂

Of all the plugins that I have to make dynamic as part of my work in GSoC ’12, logging_gearman was one. This plugin is used to log all the queries to a gearman server. After making that dynamic, here is small write-up describing how it works.

This plugins register 2 variables with the server, namely, logging_gearman_host and logging_gearman_function. Logging_gearman_host specifies hostname on which the gearman server is running and logging_gearman_function is the gearman function to which the logging information is sent. Making this plugin dynamic required to make both of these variables dynamic, so that their values can be changed at run time.

Demo of dynamic logging_gearman in action
Make sure gearman in installed and running on your system.

sudo apt-get install gearman-server
sudo apt-get install gearman-job-server

Start drizzle server with logging_gearman plugin loaded.

ansh@ubuntu:~/repos/drizzle/logging_gearman_dynamic$ drizzled/drizzled –plugin-add=logging_gearman

As we have not passed any argument for logging_gearman_host and logging_gearman_function, default arguments will be used for both of them. Default value of these are ‘localhost’ and ‘drizzlelog’ respectively.

Now add a background job to the job server for function drizzlelog

ansh@ubuntu:~$ gearman -f drizzlelog -d

-d is to run this job in background

Now go to your drizzle client and make any query with the server.

drizzle> SELECT 1;
| 1 |
| 1 |
1 row in set (0.000581 sec)

Now this should have been logged to the gearman job with the specified function running. Lets check it now.

ansh@ubuntu:~$ gearman -f drizzlelog -w
1339833870643631,1,9,””,”SELECT 1″,”Query”,237936150,88,88,1,0,0,0,1,”ubuntu”

As we can see here, the query that we made with the server is logged with the gearman job.

Now lets check what may be dynamic in this plugin. Lets say for example, we want to change the function to which we want to send our logging information. Let it be, for example ‘log’  instead of ‘drizzlelog’. For this we will start another gearman job with function ‘log’.

ansh@ubuntu:~$ gearman -f log -d

Now we will change the global variable which corresponds to gearman function in our drizzle server.

drizzle> SHOW VARIABLES LIKE “%gearman%”;
| Variable_name | Value |
| logging_gearman_function | drizzlelog |
| logging_gearman_host | localhost |
2 rows in set (0.000725 sec)drizzle> SET GLOBAL logging_gearman_function=”log”;
Query OK, 0 rows affected (0.000401 sec)

drizzle> SHOW VARIABLES LIKE “%gearman%”;
| Variable_name | Value |
| logging_gearman_function | log |
| logging_gearman_host | localhost |
2 rows in set (0.000664 sec)

Now we will check if these queries are logged into the gearman job with function ‘log’ running.

ansh@ubuntu:~$ gearman -f log -w
1339834035673149,1,6,””,”SET GLOBAL logging_gearman_function=\”log\””,”Query”,40936194,103,103,0,0,0,0,1,”ubuntu”1339834037806111,1,7,””,”SHOW VARIABLES LIKE \”%gearman%\””,”Query”,43069156,347,205,2,2,0,0,1,”ubuntu”

As we can see here, these queries are logged into the new gearman job.

Similar is the case with logging_gearman_host. We can change the host to some other hostname on which the required gearman job is running. Showing this in demo is not possible, though.

To check the code making this plugin dynamic, please refer to

Report 2

Last week was mostly spent in fixing the issues that were coming while saving the file path as system variable. As explained in my last post, this problem was due to boost::filesystem::path and std::string being unrelated types and an explicit cast can be dangerous. Daniel and I, after discussing some approaches, sorted out a solution.

A Small Hack

What we need to do actually is to store boost::filesystem::path as a system variable and there is no such datatype supported by drizzle currently. The most optimal solution would have been constructing something like sys_var_fs_path variable but it was out of scope for the current project. This problem can be bypassed in a simpler way by using a separate std::string variable which will always be same as fs::path variable. The system variable is registered using this std::string instance and whenever the file path is changed from the drizzle server, both these variables are updated with the new value. Even if certain internal fs::path methods are called, they will continue to work normally using the fs::path instance.

Auth_file plugin

Apart from doing this work and getting this reviewed, I also worked on making auth_file plugin dynamic. In this plugin, we provide a separate passwords file containing the username:password pair for all the users who can access the server. The task of making this dynamic just involved clearing the old cache (which stored username:password pairs given in the previous file) and updating this with the new username:password pairs. Most of the task involved in this was the same as regex_policy plugin.

Am currently working on auth_http plugin which uses apache mod_auth module for authentication. Will keep posting the progress.

Weekly Report 1

Officially started off with the work on 21st May. This week was mostly spent in making the regex_policy plugin dynamic. Although the plan in the proposal was a bit different and the task allotted for first week was filtered_replicator plugin, Daniel and I sorted out the plugins in the increasing order of their difficulties and hence regex_policy plugin.

Here is my first weekly report for GSoC ’12


I started off with regex_policy plugin as it seems to be the most trivial one. This plugin uses regex based authorization to match policies given in the policy file. As was pointed out by Daniel, the plugin was fundamentally designed to be static and the hack to make it dynamic was supposed to be not too complex in order to avoid future confusions, this required writing new code as well as redesigning the existing code.

Work Done: The regex_policy plugin specifies a file which either is given by the user at the time of startup of server or if not specified, a default file is used. The work was to give user the facility to dynamically change the policy file on runtime so that all the policies in the system will be reloaded with the policies given in the new file. Few approaches which were tried to accomplish this were

  • A lock variable (say regex_policy_autoreload) was used. Whenever user needs to change the policy file, he will have to explicitly make this lock as true and then the policy file will be refreshed every minute. This lacked the functionality of change of policy file. Also it involved some other critical issues like “what if user is still editing the file after a minute”.
  • After the failure of previous idea, the autoreload variable was removed and was changed to a variable reload (i.e. regex_policy_reload). The flow was to first set the regex_policy_reload to true and then change the policy file at runtime (i.e. SET GLOBAL regex_policy_policy = “path/to/new/policy/file”). After reloading the policies, the reload variable was changed to false automatically to show that the policies have been refreshed. This use of a second variable was redundant as anyone who wants to change the policy file can change the reload variable as well (hence no real kind of lock). This was removed in the next version.
  • After both the earlier approaches proved to be non optimal, finally refresh functionally was directly put into for regex_policy_policy variable and now policy file can be changed at runtime by using SET GLOBAL regex_policy_policy = “path/to/new/policy/file” or can be reloaded using SET GLOBAL regex_policy_policy = @@regex_policy_policy.

Difficulties faced: The main problem that am facing is the type of policy file in Policy class is boost file system path and there isn’t any such data type for database variables. Although this can be explicitly cast to std::string (after fs::path::string() doesn’t seems to work) but these are purely unrelated types and this may cause problems as there may be some internal fs::path methods which are being called and cannot be used with std::string. Daniel and I are still working on this to make sure this doesn’t come up in future.

The anticipated surprise

Opened the Google package (for which I was waiting since the day when GSoC results were out ;)) today. Although the package arrived yesterday, I got to put my hands on it only today, had to travel all the way from my college to my home for that. After checking the size of the courier, I was a bit astonished that Google didn’t send out any surprise gift in that. The package was big enough to hold a Nexus in it. 😛 Registering the account online and setting the PIN was a breeze. Now waiting eagerly to get my card activated so that I can make the first transaction of my first salary. 🙂

Thanks Google for the appreciation.

GSoC Proposal

 Personal Information

Name: Anshu Kumar


Nationality: Indian


Skype Name: ansharyan015

IRC Nick: Anshu

Homepage URL:

Phone: +91-8400934537

About Myself

I am Anshu Kumar, an undergraduate student and an avid developer. I am currently pursuing my Integrated Dual Degree in Computer Science and Engineering at Institute of Technology, BHU, India. I am enthusiastic about open source projects and open standards and want to be a part of open source movement. I like to play cricket and roam around in my free time.

Project Overview

This project involves making a number of drizzle plug-ins dynamic, so that they don’t require restarting Drizzle to change their settings (options and variables).

The targeted high level goals for this project will be

1. Dynamic Plug-ins – Currently, in the Drizzle codebase, only 2 plugins are dynamic, query_log and auth_schema. Other plugins require restarting drizzle in order to change their configuration. This feature will target at making some more plugins dynamic, so that their behavior can be changed dynamically by changing their variables. 

It will consist of

  • default config or default values. There will be some default settings for each of the plug-in. Drizzle will start with those default values only.
  • ability given to user to dynamically change the plug-in configuration. So, even if the default configuration is ridiculous and don’t suit some users, they can be reconfigured, without having to take the pain of restarting Drizzle.

2. Look and Feel – The plugins were developed by different people at different times, so their looks and feel is not uniform. This goal will target at making their look and feel a consistent, so that new users don’t have to learn each plug-in separately.

3. Namespaces – Namespaces in current plug-ins are not consistent. While making the plug-ins dynamic, the focus would also be on making the plug-in namespaces consistent.

Project Implementation

The work will be done by picking up a plug-in at a time and doing what required to done for that particular plug-in in order to make it dynamic. Below is a list of plug-ins with their respective development strategies

1. Filtered_replicator : This plug-in filters replication events based on schema names and table names. Even if Drizzle is started with this plug-in, there are some initial configurations which need to be set while starting it. There is a requirement for dynamic variables, so that Drizzle can be started with some default settings and these variables can be set afterwards.

2. Regex_policy and Auth_file : Regex_policy is an authorization plugin which uses regex pattern to match policies. Once Drizzle is started with this plug-in, if the administrator wants to change the policy file, the new policy won’t be effective due to the static behavior if the plugin. Policies are loaded in the system, only when Drizzle is started. It would be modified to reload the regex policy file dynamically so that the corresponding changes in policy are reflected immediately in the system without restarting Drizzle. There would be a reload variable which will be used to dynamically reload the policy file. After changing the policy file, making the status of reload to true will reread the policy file and stores it. The value of reload variable will be set to false from the code itself to reflect that the policy file was reloaded.
Auth_file  is an authentication plug-in that authenticates connections using a list of username:password entries in a text file. Here also, once Drizzle is started, changes in the users file are not reflected in the system. This would also be made dynamic by implementing auto reload of users file upon any modification. Same kind of development strategy will be followed as was followed for regex_policy plugin.

3. Syslog, logging_query and logging_gearman: This plug-in handles the interface for query logs, error messages and functions. This plug-in defines its own set of variable specifying the behavior of logging of different logs into syslog. But this behavior cannot be changed dynamically. These variables would be made dynamic so that the logging behavior can be changed at runtime. There will be some handler functions for each of the variables which will be made dynamic and when they are changed dynamically, the handler function will ensure that the proper action takes place after changing them.
Logging_gearman and Logging_query module enables the logging of queries to a gearman server and to a CSV file respectively. The behavior of plug-in variables will be made dynamic so that they can be changed at runtime and the corresponding behavior change will appear immediately in the system.

4. Auth_http and auth_ldap : These are the authentication plug-ins respectively which are used for user authentication on basis of HTTP URL authentication and LDAP authentication respectively. The server support would be made dynamic so that the respective variables can be dynamically changed. Handler function will be attached with each of the dynamic variable which will handle the required changes which needs to be done upon changing that variable.

5. Memcached_stat : This plug-in provides memcached server statistics as INFORMATION_SCHEMA tables. The respective variables corresponding to the plug-in would be made dynamic so that they can be changed at runtime and the changes start to appear without the need to restart Drizzle. Also there is no default value added to the variable. There would be a default variable which can be changed later having drizzle started up.

6. Rabbitmq and zeromq : Making rabbitmq will involve making the attached variables dynamic so that all the settings like the hostname, port and name, password, etc can be configured at runtime and this way the replication events can be controlled for the Drizzle. This would involve some more complex work as compared to other plug-in as here we will have to dynamic establishment of connection to a Rabbitmq server after changing the variables.
Making zeromq dynamic will involve the similar approach for making the zeromq endpoint dynamic for changing the endpoint (to expose public transactions) dynamically.

Additionally, the ‘look and feel’ and namespace issues of the plug-ins will be handled together while doing the modifications for making them dynamic so that it would not require any more effort doing all these.

Schedule of Deliverables

Pre project period: Understanding codebase of Drizzle and understanding the plug-in architecture of Drizzle. This will broaden my knowledge about how to modify the plug-in to get the thing done. This period will also involve some brainstorming of ideas with mentor to come to the most optimal solution for each of the plug-in. Towards the end of this period, I would be able to determine how to make them dynamic.

Week 1: Filtered_relicator plug-in would be made dynamic. This period will also involve understanding the capabilities of this plug-in to make the dynamic thing sensible. Testing will also be done for this. Towards the end of this period, this plug-in would be made dynamic.

Week 2-3: In this period regex_policy and auth_file plug-ins will be modified. In both the plug-ins, the requirement is the same, so I will be doing them in the same time slot. Towards the end of this period, both of these plug-ins will be ready to be called as dynamic.

Week 4-5 : In this period, all the logging plugins, i.e. syslog, logging_query and logging_gearman will be made dynamic.

Week 6-7 : Memcached_stat plug-in will be concentrated upon. Server would be made dynamic. This period also includes some buffer time, because things may go in wrong directions. This buffer time will be used for backup.

Midterm Evaluations: Nearly 70% of the work would be done upto this.

Week 8-9.5: Auth_http and auth_ldap will be handled in this slot. This will involve some complex testing as both of these modules are related to authentication. By end of this period, both of these will be made dynamic.

Week 9.5-10: This period will involve understanding the architecture of rabbitmq and zeromq. Additionally, these plug-ins will be made dynamic by end of this period.

Week 11: This period will consist of final testing of plug-ins modified. Bugs shall be fixed and final deliverable will be made ready. Additionally, final changes and documentation will be done.

Apart from this, weekly progress report to the mentor shall be submitted.

My OpenSource Contribution

My OpenSource contribution started off with Drizzle itself where I fixed a bug. The submitted patch was accepted and merged with the main branch. 

After this, for having a detailed overview of this dynamic plug-in project, I started off with making the regex_policy plug-in dynamic. Thread was used to check continuously for modifications in a file and if file is modified, then it is reloaded. This particular branch can be found here.

Reasons for picking this project

I am enthusiastic about working in an open source project this summer and I feel that my contribution towards Drizzle by this project will provide me the desired experience and learning opportunities.

Most importantly, I have the knowledge of what this project demands. With my earlier coding experience with Drizzle, making the regex_policy plugin, I have explored the Drizzle codebase to a large extent and I know how things are working. Additionally, my past experience with C++ and database concepts will help me to meet the demands of this project.

Summer Commitments

I do not have any summer jobs or any other plans for this summer. I am ready to dedicate all my time this summer to GSoC and put in as much time as required to complete this project in allotted time. I will be starting the work 2 weeks prior to the official date of commencement of GSoC ’12. I assure you that I will work for atleast 7 hrs a day to complete the project comfortably within the deadline.

Past Projects

1.Web based software for Hotel Management

Developed a central system that will help management of a group of hotels by a central authority to provide complete concoction of solutions to all hotel management problems like financing, accounting, inventory management etc. In addition to general hotel management features like room reservation etc, following were also implemented:

a.Implementation of IVRS using Ribbit voice API. Room could be booked through IVRS also. SMS and Email features were also integrated using this API.

b.Flexibility in creation of graphical and statistical report for any particular hotel by the central authority.

c.Creation of complete database backup using user interface into database dump, xml, excel sheets or csv. 

Exposure: UML, J2EE, XML, e-Forms, AJAX, Web 2.0, Web Services, SOA.

Experience: This project was done in a team of two and the aim was to learn software engineering principles. This project was selected for Face to Face evaluation round of The Great Mind Challenge organized by IBM Academic Initiative.

Project Partner: Mohit Srivastava (

Project Mentor: Dr. R. S. Singh (

2.Partitioning graph to speedup Dijkstra’s Algorithm

Dijkstra’s Algorithm is a graph search algorithm that solves the single source shortest path problem for a graph with non-negative edge path costs, producing a shortest path tree. This graph is often used in routing. The aim of this project was to speed up the running of Dijkstra’s algorithm. Bidirectional search was implemented for this purpose.

Exposure: Graph algorithms

Project Partners: Akash Nawani ( and Mohit Srivastava (

Project Mentor: Dr. B. Biswas (

3.Implementation of Stream KM++

This was an extension of KMeans clustering algorithm that can be applied to data streams. This algorithm made use of two techniques

a.A non uniform sampling approach similar to the seeding procedure in K-Means++ is used to obtain small corsets form the data stream. Unlike other coreset constructions, this construction is rather easy to implements and unlike other corset constructions; its runtime has only a low dependency on the dimensionality of the data.

b.A new data structure called a corset tree was proposed. The use of this corset tree significantly speedup the time necessary for the non-uniform sampling during the corset construction

Exposure: Graph Clustering and Distributed Data Mining

Project Partner: Mohit Srivastava ( )

Project Mentor: Dr. K. K. Shukla (

4.Web Based Software for Internet Banking System

Internet Banking System is an online comprehensive solution to manage internet banking. It shall be a system that will be available to customers having a valid username and password to avail banking facilities such as fund transfer, managing their account, request for cheque book, bill payments, request for demand draft and many more.

a.Ext JS was used for designing of complete portal. AJAX was used extensively for grid reloading. Tabbed interface was implemented so that user can work on multiple things at a time.

b.HighCharts API was used to create graphical reports which provide facilities for easy reloading and saving the chart in various formats. Jasper API was used for statistical report generation.

c.IVRS was implemented using Ribbit voice API.

Exposure: UML, J2EE, XML, e-Forms, AJAX, Web 2.0, Web Services, SOA, Ext JS

Experience: This project was done in a team of 4 and main aim was to polish our software engineering skills. This project was selected for Face to Face Evaluation round of The Great Mind Challenge organized by IBM Academic Initiative.

Project Partners: Akash Nawani (,  Mohit Srivastava ( and Vikas Singh (

Project Mentor: Dr. B. Biswas (

5.Intern at OpenLifeCycle

OpenLifeCycle is a company which is into its early startup phase and is into the business of creating some Application LifeCycle Management tools. I joined here in last summer as an intern for PHP developer. The work mainly involved creating of frontend of some of their applications and writing some backend code for a few of them. Apart from this, I was involved in

a.Development of framework for AAAC (authentication, authorization and access control) so that only users having respective rights can access the resource. This involves implementation of CRUD rights for users.

b.Testing team of the complete application.

Exposure: PHP, XML, AJAX, JQuery, SimpleTest, SVN.

Experience: During my phase in the company I came across many tools which are used for managing projects in an organization. Apart from ReviewBoard and BugZilla which were used for code review, I used Hudson server for automating the build, Hiphop server for building PHP code, User Friendly SVN for repository management, Docuwiki for documentation purposes, etc.

Technical Skills and Experience

Programming LanguagesC, C++, JAVA

Database Technologies: MYSQL, IBM DB2

Operating System: Windows, Linux, CentOS

Application Servers: Tomcat, Websphere, Apache server

Web Technologies: HTML, CSS, JavaScript, PHP, JSP, XML, AJAX, JSON, Servlets, Ext JS

Tools: ReviewBoard, BugZilla, Hudson, Hiphop, Buggennie, DocuWiki, USVN.

Others: NetBeans IDE, Eclipse IDE, Visual Studio IDE, SubVersion.

GSoC 2012

Am really glad on my selection in GSoC 2012. 🙂

The reason behind my happiness is that i have been thinking of giving this a try since last three years. I never did though. And the excuses were “…you have to code like a dog and all…I don’t want to do it…GSoC is for geeks only… and a never ending list of non sense”. 😛
This was my first attempt with Summer of Code and all I can say from my experience till now is you do not have to code all day long like robots or anything. Just select a project of your choice (a project in which you can contribute really well and you have some prior knowledge about the project domain. It should not be like ‘I would like to do this but I have no idea how this can be done.’) … interact with the community continuously… communicate your problems and blockers and they will be happy to help you out. Everything else depends on your approach to the project.

The project I was selected for is “Making all plugins dynamic” with Drizzle (which provides a database forked from MySql for cloud infrastructures and web applications). My project involves making a set of Drizzle plugins dynamic so that changing their configuration would not require restarting Drizzle. Currently, if you want to change the config options, you have to make changes to the config files and then you have to restart Drizzle so that the variables are updated in the system. More description about the project can be found here. Soon be publishing the proposal that I submitted for GSoC.

Looking forward to a great and fruitful summers ahead. 🙂

Hello world!

Hey, What am I doing here?! This is the least expected place where you can find me.
Well, I have started this to share some common problems with their solutions which I come across almost daily. Theme of the contents will be mostly technical only, with some other stuffs. I have planned to make frequent updates, so keep checking and stay updated.

& TY WordPress! 🙂