It feels like there is no end to this. About 5 months have passed since I started working on this project, but even at this point there is still much to be done. Dr Shawn told me about the Pareto Principle, which I can relate to this project a lot. The formal definition states that 80% of effects come from 20% of the causes, for many events. It is also known to be the 80/20 principle. So why is it relevant to my current project? Well it can be said that 80% of a software can be done in about 20% of the total development time, but the remaining 20% of the software would take the remaining 80% of the time to finish. This realization got me flabbergasted. The major functionalities of my project can be done in considerable time, but it is the other minor, although important, functionalities that takes a longer time because there is always more and more of them coming into the picture as I come to realize later in the project.
Anyways, the bulk of this week’s work involved implementing the UI functionalities as usual. As I was doing my work, I got the idea that we could have multiple project templates in which a user can choose from when creating a new project. All this while, a project is created from a “blank” template or otherwise the default template, but that doesn’t mean it should be the only template to choose from. With that, however, I need to make changes to the backend. There is now a specialized folder where the project template archive files would be, so new templates can be added to that folder. The template archive file is added to the cache, when a new project is created. At the moment, the only way I could think of requesting a specific template is by passing the template’s name as a query parameter when sending a POST request to the cache REST endpoint like so:
POST /api/v16/cache?project={UUID}&template=blank
So the template parameter in the above request would correspond to the name of the blank template archive file, i.e “blank.zip”, and copy it to the cache. If a non-existant template name is given then the server application would return a 404 status.
Moving on, whenever I make any changes on the front end, I would refresh in the browser so that I could see the new changes. Doing this would make the application start from the beginning again, like mounting the storage, list all projects and boards from the database and so forth. The request to mount the storage must always comes first, in order to load the database file from the storage to the cache, and then the meta data for projects and boards for a particular user can be retrieved from the database. The requests for reading projects and boards can be done concurrently, and axios enables you to do that. However, the server occasionally crashes when the concurrent requests is made, or it will be restarted if its running as a daemon. This is a very serious issue. I ran the application within the GDB debugger, and when the crash occurs, I get a stack trace to see where the application is crashing. It turns out the crash occurs when reading the JSON payload from a decoded JWT. The stack trace shows the crash occuring in some function from the boost json_parser. Searching the web for answers, apparently boost’s json parser is not thread safe by default in Ubuntu.
Based on this Stack Overflow discussion, I have to add a #define macro before including any of the property tree header files to enable thread safety. The boost json_parser is used a lot in the backend so I have to add the macro in places where the header files are included. I thought that would be the end of it, but the crash still occurs sometimes when the concurrent requests take place. I’ve decided to move on from this problem first, as there are other things to be done.
Dr Shawn gave me this month to finish up the project. I hope I’ll be able to resolve everything at the end of it. Peace out.
0 Comments