Permalink
Commits on May 27, 2013
  1. Small documentation fixes

    goldmann committed May 27, 2013
Commits on May 20, 2013
  1. TORQUE-1075 - Use service name in :inspect implementation

    It was fixed by implementing the inspect method in the service, since
    JRuby did not a good job at creating the object inspection on its own.
    goldmann committed May 20, 2013
Commits on May 9, 2013
  1. [TORQUE-1090] Improper assigning of the name instance variable in Tor…

    …queBox::Messaging::Queue and Topic when using the javax.jms.Destination as the destination
    
    Fixes the issue where TorqueBox.fetch sends javax.jms.Destination object
    as the first argument of the constructor in TorqueBox::Messaging::Queue
    (and Topic) class. The TorqueBox::Messaging::Queue class stores
    thisobject in @java_destination instance variable instead of messing the @name
    variable.
    goldmann committed May 9, 2013
Commits on Apr 23, 2013
  1. Removing Gemfile.lock files when running integs

    Sometimes when running integs and changing the gems structure we will
    end up with invalid entries in Gemfile.lock. Let's remove these files
    before running integs.
    goldmann committed Apr 23, 2013
Commits on Apr 22, 2013
  1. [TORQUE-959] expose the message_ttl for backgroundable futures

    This commit makes it possible to change the message ttl for the future
    message.
    goldmann committed Apr 19, 2013
Commits on Apr 12, 2013
  1. [TORQUE-1069] Make it possible to create queues and topic at runtime …

    …in the way they are created currently at boot time
    
    [TORQUE-1053] Use QueueInstaller to create queues using TorqueBox::Messaging::Queue.start method
    
    This commit fixes both issues. The newly introduced Destinationizer
    service is now responsible for creating destinations (queues and topic)
    across TorqueBox. It does not talk directly to the HornetQ server and it
    utilizes the QueueInstaller (or TopicInstaller) classes from polyglot.
    
    The change itself results in a small overhead when creating the queues
    (two MSC services are deployed) but it's a trade-off to have the
    destination creation process same across different deployment methods.
    
    This way we end up with a consistent creation of the destinations, both
    at deployment and at runtime.
    
    Destinationizer itself executes the creation in an asynchronous way
    returning CountDownLatch to optionally wait for the task completion.
    
    Additionally the TorqueBox::Messaging::Queue and
    TorqueBox::Messaging::Topic documentation was rewritten to use the
    proper yardoc tags.
    goldmann committed Apr 9, 2013
  2. Changes to the way jobs are createdand removed.

    Now the runtime scheduling using the .schedule, .at and .remove methods
    are executed asynchronously. These methods return CountDownLatch object
    so we can block (if needed) to wait for the task completion or save it
    for later use.
    
    New methods schedule_sync, at_sync and remove_sync were created to
    execute the task in a scynchronous way returning true or false depending
    on the outcome.
    goldmann committed Apr 11, 2013
Commits on Apr 3, 2013
  1. Wrong metadata, thanks Toby

    goldmann committed Apr 3, 2013
  2. Make sure the job_schedulizer service name is unique across the

    deployment when using with immutant and overlay.
    goldmann committed Apr 3, 2013
Commits on Mar 28, 2013
  1. Use of CountDownLatch instead of ExecutorCompletionService. This makes

    watching for the service installation/removal easy.
    
    Documentation for the ScheduledJob class and JobSchedulizer was
    extended.
    
    Removed the "should timeout" integ since it doesn't make sense after
    removing the :wait option. The timeout is set now to 30s in
    JobSchedulizer.
    
    Fixed manual after removing the :wait option.
    goldmann committed Mar 28, 2013
Commits on Mar 27, 2013
  1. Added docs for TORQUE-860

    goldmann committed Mar 27, 2013
  2. [TORQUE-860] Allow to deploy Message Processors and Jobs stopped

    Allows to deploy message processors and jobs stopped. This feature will
    make it possible to start jobs and message processors but not to run
    them at application boot time.
    
    Three new methods were exposed for message processor management: start,
    stop and started?.
    
    This commit includes integration tests.
    goldmann committed Mar 27, 2013
Commits on Mar 26, 2013
  1. Allow to set the 'stopped' parameter for jobs and message processors

    both in yaml and Ruby deployment descriptors. By default 'stopped' is set
    to false.
    goldmann committed Mar 26, 2013
  2. Revert "Be a bit looser on the at_job integ expected counts"

    This reverts commit b35cf5a.
    goldmann committed Mar 26, 2013
Commits on Mar 25, 2013
  1. [TORQUE-257] Provide support for 'at' jobs

    Added suport for new way of scheduling jobs:
    
    The job will be executed every 200 ms, from now, for the next 10 seconds
    TorqueBox::ScheduledJob.at('SimpleJob', :every => 200, :until => Time.now + 10)
    
    The job will be executed for the first time in 10 seconds (current time + 10 seconds), then every 500 ms, for the next 10 seconds (current time + 20 seconds)
    TorqueBox::ScheduledJob.at('SimpleJob', :at => Time.now + 10, :every => 500, :until => Time.now + 20)
    
    The job will be executed for the first time in 5s and repeated 3 times. The time between executions is set to 1.5s
    TorqueBox::ScheduledJob.at('SimpleJob', :in => 5000, :repeat => 3, :every => 1500)
    
    Added integration tests and documentation.
    goldmann committed Mar 18, 2013
Commits on Mar 22, 2013
  1. Fix the location of the module

    goldmann committed Mar 22, 2013
  2. Make the remove and schedule calls remove true when the task finishes

    successfully and false in case of timeout.
    
    Updated docs to reflect the changes.
    goldmann committed Mar 22, 2013
  3. Now the asynchronous calls to schedule or remove a ScheduledJob return

    ExecutorCompletionService which can be used to determine if the task
    (scheduling or removing the job) is finished.
    
    We use the pool(long, TimeUnit) methond in schedule and remove methods
    in the TorqueBox::ScheduledJob module. By default we'll wait 10 seconds
    for the task to finish, but it's configurable by passwing the :wait
    parameter to the schedule or remove calls. Specified value must be in
    miliseconds.
    
    TorqueBox::ScheduledJob.remove('JobClass', :wait => 5_000)
    goldmann committed Mar 21, 2013
Commits on Mar 19, 2013
  1. More docs in the Ruby code

    goldmann committed Mar 18, 2013
  2. Added an option to remove a deployed scheduled job. The remove method is

    executed asynchronously and does not return any value.
    
    TorqueBox::ScheduledJob.remove('job.name')
    
    The scheduled job integration tests were extended.
    goldmann committed Mar 18, 2013
  3. Removed ScheduledJobInstaller. Moved all job creation to the JobSched…

    …ulizer service. Deploying jobs from deployment descriptors is done now when the JobSchedulizer is being started.
    goldmann committed Mar 16, 2013
  4. [TORQUE-674] Allow runtime scheduling of jobs

    This adds initial support for scheduling jobs at runtime:
    
    TorqueBox::ScheduledJob.schedule('SomeJob', "*/10 * * * * ?")
    TorqueBox::ScheduledJob.schedule('SomeJob', "*/10 * * * * ?", :name => "somejob", :description => "A simple job", :singleton => true, :timeout => "5s")
    
    Please note that singletons are untested so far.
    
    The job name is required, but if do not specify it a default vaule of
    'default' will be used. Please note that there cannot be two jobs with
    the same name for one deployment unit (application).
    
    More technical stuff:
    
    This commit removes usage of BaseRubyComponentInstaller and moves all
    the still required method to a ComponentResolverHelper helper class to
    use them also in services that modify services at runtime.
    
    A new JobSchedulizer class was introduced which is responsible for
    runtime jobs scheduling.
    
    RubyJobProxyFactory was removed and the logic was moved to
    BaseJobScheduler.
    
    JobComponentResolverInstaller was removed, since we initialize component
    resolvers at runtime now (see ComponentResolverHelper and
    JobSchedulizer).
    
    In JobSchedulerInstaller we install one or two JobSchedulers depending
    on the environment. One in case of a regular, non-clustered environemnt,
    two (a regular and a singleton one) in case we have a clustered
    environment.
    goldmann committed Mar 14, 2013
Commits on Mar 7, 2013
  1. [TORQUE-1025] expose expireMessage, sendToDeadLetterQueue, and moveMe…

    …ssage methods
    
    Exposed new queue management methods like: expire_message, expire_messages, move_message, move_messages. This commit allows also to set dead letter and expiry destination. Please read documentation in the code for usage.
    goldmann committed Mar 7, 2013
Commits on Mar 6, 2013
  1. [TORQUE-1031] Web contexts should be normalized

    Was fixed in polyglot, but adding integration tests here to make sure it works as expexted.
    goldmann committed Mar 5, 2013