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.
…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.
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.
This commit makes it possible to change the message ttl for the future message.
…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.
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.
This reverts commit e4be8e4.
deployment when using with immutant and overlay.
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.
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.
both in yaml and Ruby deployment descriptors. By default 'stopped' is set to false.
…o the scheduler
This reverts commit b35cf5a.
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.
successfully and false in case of timeout. Updated docs to reflect the changes.
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)
executed asynchronously and does not return any value. TorqueBox::ScheduledJob.remove('job.name') The scheduled job integration tests were extended.
…ulizer service. Deploying jobs from deployment descriptors is done now when the JobSchedulizer is being started.
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.
…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.