It seems like there is some scheduler functionality involved here as well...
Now I am still missing some
ScheduledTask
Scheduler
SchedulerUtilities
near the
package org.itracker.web.scheduler.tasks;
I think we are using Java mail for the messaging. And we also have some Quarz stuff. But how actually the Scheduler and the Notification is depending on each other - I don't know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It seems like there is some scheduler functionality involved here as well...
Now I am still missing some
ScheduledTask
Scheduler
SchedulerUtilities
near the
package org.itracker.web.scheduler.tasks;
I think we are using Java mail for the messaging. And we also have some Quarz stuff. But how actually the Scheduler and the Notification is depending on each other - I don't know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In my understanding, notifications are sent in batches and are not sent right away.
There will be a predefined schedule for sending notifications. For me this makes sense so as not to choke the server of sending notifications right away.
Quartz handles the scheduling part like a cron job that lives within the webapp. When a cron job is due, it triggers the Java mail code to do the actual notification sending.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The notifications should get sent "rigth away", so that all participants and watchers get notified, when an issue gets a new entry, status changes, etc.
People (at least some people) seem to love this functionality (others don't like to be notified but in 2.4.2 everybody involved gets notified... the only way to opt out is to set the e-mail to null directly in the database ;->).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, then let's do the instant sending of messages. :)
Reading through the codes, the scheduler is used for reminder notifications. (sends reminders to all owners/admins of unresolved issues in all projects that have not been modified in 30 days.)
Let's add an attribute in the UserPreferences tables to have the user the option to receive emails or not.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Notifications, even 'direct' in case of Issue creation/update should be sent in an asynchronous way, triggered by the involved service. This could increase performance while editing issues and would allow to send more detailed and even localized notifications too.
There should be a way to register a notification, and a high-frequent Scheduler (every minute/configurable) would send the notifications in a same matter as the previous reminder task.
It could be necessary, to save notifications to send in database before they will be processed, probably new entity with queue character.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=1008661
Originator: YES
It seems like there is some scheduler functionality involved here as well...
Now I am still missing some
I think we are using Java mail for the messaging. And we also have some Quarz stuff. But how actually the Scheduler and the Notification is depending on each other - I don't know.
Logged In: YES
user_id=1008661
Originator: YES
It seems like there is some scheduler functionality involved here as well...
Now I am still missing some
I think we are using Java mail for the messaging. And we also have some Quarz stuff. But how actually the Scheduler and the Notification is depending on each other - I don't know.
Logged In: YES
user_id=264705
Originator: NO
In my understanding, notifications are sent in batches and are not sent right away.
There will be a predefined schedule for sending notifications. For me this makes sense so as not to choke the server of sending notifications right away.
Quartz handles the scheduling part like a cron job that lives within the webapp. When a cron job is due, it triggers the Java mail code to do the actual notification sending.
Logged In: YES
user_id=1008661
Originator: YES
The notifications should get sent "rigth away", so that all participants and watchers get notified, when an issue gets a new entry, status changes, etc.
People (at least some people) seem to love this functionality (others don't like to be notified but in 2.4.2 everybody involved gets notified... the only way to opt out is to set the e-mail to null directly in the database ;->).
Logged In: YES
user_id=264705
Originator: NO
OK, then let's do the instant sending of messages. :)
Reading through the codes, the scheduler is used for reminder notifications. (sends reminders to all owners/admins of unresolved issues in all projects that have not been modified in 30 days.)
Let's add an attribute in the UserPreferences tables to have the user the option to receive emails or not.
Notifications, even 'direct' in case of Issue creation/update should be sent in an asynchronous way, triggered by the involved service. This could increase performance while editing issues and would allow to send more detailed and even localized notifications too.
There should be a way to register a notification, and a high-frequent Scheduler (every minute/configurable) would send the notifications in a same matter as the previous reminder task.
It could be necessary, to save notifications to send in database before they will be processed, probably new entity with queue character.