Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Since you want the jobs processing to be in a separate JVM from your front-end application, the easiest way to do that is to have two instances of Grails running, one for the front-end that serves web requests, and the other to deal with job processing.</p> <p>Thankfully, the rich ecosystem of plugins for Grails makes this sort of thing quite easy, though perhaps not the most efficient, since running an entire Grails application just for processing is a bit overkill.</p> <p>The way I tend to go about it is to write my application as one app, with services that take care of the job processing. These services are tied to the RabbitMQ plugin, so the general flow is that the web requests (or quartz scheduled jobs) put jobs into a work queue, and then the worker services take care of processing them.</p> <p>The advantage with this is that, since it's one application, I have full access to all of the domain objects, etc., and I can leverage the dissconnected nature of a message queue to scale out my front- and back-ends seperately without needing more than one application. Instead, I can just install the same application multiple times and configure the number of threads dedicated to processing jobs and/or the queues that the job processors are looking at.</p> <p>So, with this setup, for development, I will usually just set the number of job processing threads to whatever makes sense for the development work I'm doing, and then just a simple <code>grails run-app</code>, and I have a fully functional system (assuming I have a RabbitMQ server running to use as well).</p> <p>Then, when I go to deploy into production, I deploy 2 instances of the application, one for the front-end work and the other for the back-end work. I just configure the front-end instance to have 1 or 0 threads for processing jobs, and the back-end instance I give many more threads. This lets me update either portion as needed or spin up more instances if I need to scale one part or the other.</p> <p>I'm sure there are other ways to do this, but I've found this to be both <em>really</em> easy to develop (since it's all one application), and also really easy to deploy, scale, and maintain.</p>
    singulars
    1. This table or related slice is empty.
    1. POCorrect way to implement standalone Grails batch processes?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. UScdeszaq
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POCorrect way to implement standalone Grails batch processes?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COThis makes sense. But how do you launch the threads which process the incoming RabbitMQ tasks? With Grails 'executor' plug-in or some other way? My problem is that the tasks are very long-running (hours), so I would prefer to manage each as individual process, but I guess that is not possible.
      singulars
      1. PO
      1. USJohn M
    2. COI just rely on the Grails RabbitMQ plugin to manage the threads, so messages just get delivered to the `handleMessage` method and it does whatever it needs to to process the message (which is a job in this case). With tasks that long, the only concern I would have is any ACK timeouts that the RabbitMQ server would have (those would need to be tuned, perhaps), but otherwise there shouldn't be any issues. That's the beauty of a message queue... the jobs will just wait until they get picked up, so run-time on the jobs doesn't really matter.
      singulars
      1. PO
      1. UScdeszaq
    3. COTo manage each task, just have each task be it's own service, and then have an instance of your application for each of these services that you want to be able to manage separately. They key to it all is to use external config config.groovy files to override the "defaults" in your primary config.groovy so that you can tweak the RabbitMQ exchange / queue bindings (to be able to ignore certain job queues for an app instance) and also the number of concurrentConsumers.
      singulars
      1. PO
      1. UScdeszaq
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload