Glassfish_logo.svgI manage a small application that is hosted on a single Linux virtual machine and have noticed some occasional performance and stability issues.

The server runs CentOS, MySQL and a GlassFish server. I chose GlassFish several years ago because at the time it was the only EJB3 container around, as well as being very well integrated with the NetBeans IDE.

Like most JavaEE containers, it also makes clustering and scaling easier. Continue reading

I was reminded a couple of days ago of the danger of using tools that help you to get things up and running quickly, by a question that I was asked in an interview. The question was pretty simple, but not something I’d thought about for a while, which was: “What are the verbs used in RESTful services?”.

 

Now intuitively I know that answer, but hadn’t really thought about it for a while, so I basically answered incorrectly (mostly because I suck at inteviews), only remembering that you do GET and POST in HTTP, so responding that GET is to query and POST is for inserts/updates.

Of course I know the reality (and one of the advantages) of RESTful services is that they behave by contract, so they can use the full complement of the HTTP verbs, and the convention is to use each one for a specific purpose:

  • GET – used to get or retrieve a resource (always returns the same resource for the same query).
  • POST – used to create a new resource (returns the location for the newly created resource).
  • PUT – used to replace a resource (typically an update).
  • DELETE – used to remove a resource
  • OPTIONS – sometimes used to describe information about what verbs a service can use for a specific URI (not normally implemented however).

But the last few times I’ve done RESTful services, I’ve simply let an IDE generate them for me, so I haven’t even thought about those last statements. In the IDE, all I had to do was say I wanted to add REST (using Jersey) to my session beans, and voila, I have a full fledged RESTful service.

And of course on the consuming side, all I have to do is call the right method, and under the covers the Jersey client stuff does the right thing about which verb to use. So I’m not actually thinking about what’s under the covers, and because of that wouldn’t be quick on my feet about how the service is constructed under the covers.

There are of course pros and cons to approaching code in this way. In the early days of writing code, we all had to know what the machine language underneath looked like. Modern languages hid that complexity from us, and reading assembly language became a lost art practiced by rocket scientists and performance gurus.

By hiding the complexity we have been able to develop insanely complex applications that would not have been possible without those building blocks. Freeing ourselves with increasingly general patterns in code, we are able to focus on solving the problem at hand, and stand on the shoulders of those that go before us in doing so.

I don’t expect to need to write a RESTful service from scratch any time soon, but it is a good reminder that when you rely on tools to build your code, you are risking living with a lack of understanding of the underlying mechanism, which could make it difficult to know about the pros and cons of a solution.

 

Enhanced by Zemanta

I ran into an odd problem with the way Cake is coded that tripped me up for a couple of days. Because I hate it when things don’t work the way I think they should, I spent way more time debugging this than anybody should.

I got my basic RESTful service working for the VolunteerCake project, and everything was working swimmingly, until I needed to turn on debug to figure something out …

When I had the debug level set to less than two (2) calling the action I was interested in with an extension of “.xml” was working fine. I got back the XML representation of the data in the action I was interested in returned with content-type of “application/xml”. In Cake, if you turn debug to 2 (or 3) it will dump out the SQL that was run in an HTML table.

The problem is that this HTML table is actually spit out  after the rest of the view, meaning that my RESTful service no longer has a well formed document to display. Additionally (for reasons I’ve yet to isolate), when this happens, the document is returned with a content-type of “text/html” instead of “application/xml” as expected. Neither of these things would be acceptable if the site is to provide web services, since it would mean the web services would be broken as soon as somebody needed to debug.

The workaround for this is to manually reset the debug level when the extension of “xml” is detected. Since the debug data is useful, and it’s just the SQL that appears to break the XML, I asked on the IRC channel what the last place I could set the debug might be. The suggestion was to put it either in the afterFilter, or the end of the view itself.

I found that if I put the following code into the beforeFilter method, I could prevent the problem with the price of losing my debug output:

That same code placed in the afterFilter method gave me the debug output in a well formed XML document (excluding the SQL table), as did placing it in the view itself. This leads me to believe that when debug > 1 there is some code that happens after the beforeFilter that is not setting the content type to “application/xml” as would be expected from our routing rules.

Being the bulldog that I am, I dug into the Cake source code to see if I could figure this out. I found the spot where the SQL table was being built, which turned out to be in the showLog() method of the dbo_source.php, which is called by the close() method. Since the close() is called after the view is finished, and the showLog() method simply prints the data, that explains why it breaks the XML. It definitely breaks the MVC encapsulation, since the data gets dumped into an HTML table and spit out after the view is complete.

On the IRC channel, it was suggested that I try creating a data source that would override the showLog method and spit that table out to a table, which might be worth trying.

I posted my question on the CakePHP Google Group and got the useful suggestion to use the FirePHP plugin which basically writes the log data to the FirePHP plugin so it can be displayed in FireBug. So my approach will be to write a dbo_mysql_firephp.php class that does just that. This will at least resolve the MVC encapsulation issue and keep my view relatively clean.

I still want to figure out exactly why the content-type isn’t getting set properly, but for now I have a workaround that I’ll use, and I’ll add the FirePHP debugging to solve the well-formed XML issue if I ever do figure out the content-type problem.

Off to set up my FirePHP plugin and build the dbo class now …

Enhanced by Zemanta

I’m on a quest to make my application provide RESTful web services. After much digging, I found a post by Chris Hartjes at http://www.littlehart.net/atthekeyboard/2007/03/13/how-easy-are-web-services-in-cakephp-12-really-easy/ that helped a lot.

Turns out that Cake has some really nifty built in support that can be turned on really easily. For basic XML support, all you need to do is to add a couple of lines to your routes.php file to allow Cake to handle XML. This is pretty well described in the Cookbook at http://book.cakephp.org/view/477/The-Simple-Setup

So for my VolunteerCake project I added the following lines to my routes.php:

The mapResources() does the magic that maps the REST requests to the actions in the controllers, and the parseExtensions() sets up Cake to do some other routing magic when the request has a “.xml” extension.

So now if I call any of my actions and append “.xml”, Cake changes the response type and view to return XML. Next we need to add the view for the XML, which goes in the xml directory under the view we are REST enabling (e.g.- for jobs, we have a views/jobs/xml directory where the view CTP files need to be placed).

First I created the xml directory under the views/jobs folder, and next I created an index.ctp. This is a very simple file, which Cake’s XML helper to spit out the data with the following code:

Now to get the XML to display, all I have to do is create the appropriate views for my REST actions.

So for example if I go to the app/jobs action, I would normally see the XHTML representation of the page like:

VolunteerCake Jobs

Then if I append “.xml” to that same URL, I get the XML back as shown in the following screen shot:

Screen Shot 2013-06-16 at 10.51.23 AM

Next we need to do the view.ctp to provide support for sending back the data for a specific job by ID. This is practically identical to the index.ctp, except we’ve modified the code to use the variable $job instead of $jobs (since that’s what Cake returns):

This allows us to get the behavior of being able to get the XHTML for a specific job by using a url like /jobs/view/1 as shown:

Screen Shot 2013-06-16 at 10.53.03 AM

 

Then by appending “.xml” to that same URL, we get the XML for the job with ID of 1:

Screen Shot 2013-06-16 at 10.55.35 AM

You may notice that the XML for this Job has a lot more data than we saw when we got the list for the specific Job. The XML from /jobs.xml is only one level deep, while the data from /jobs/view/1.xml has a hierarchy of a job having slots, which in turn has a job, user_slot and user.

That happened because the index action was set up to only get the data from the Jobs, while the view action had recursion set in order to gather all the related data. By setting the recursive var to 0 (zero) in the index action, we get no children, while in the view action we set the value to 2 (two) which tells cake to fetch all the HABTM data (see: http://book.cakephp.org/view/439/recursive for more on this). Alternatively we could do a specific find and modify which bits of data we populate in the controller to determine what data gets spit out in the XML (this would alleviate the one potential downside to this approach which is that ALL of the data fields and tables are currently being placed out in the XML stream).

The basic point here is that we now have a working RESTful service (at least as far as fetching data) that doesn’t require a great deal of specific view code.

Next: completing the RESTful CRUD

Enhanced by Zemanta