You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by hwaastad <he...@waastad.org> on 2013/12/15 18:42:54 UTC
TomEE and persistent timers
Hi,
until now I've just used standard config for my @schedule processes.
However in my quest for clustered setup I've started to look into persistent
storage for quartz.
Now, I'm quite new to quartz so I might be missing out on something so I
hope you can bear with me :-)
application.properties:
org.quartz.scheduler.skipUpdateCheck = true
org.quartz.scheduler.instanceName = TestScheduler
org.quartz.scheduler.instanceId = AUTO
org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool
org.quartz.threadPool.threadCount = 5
#org.quartz.threadPool.threadPriority = 5
#org.quartz.jobStore.misfireThreshold = 60000
#org.quartz.jobStore.clusterCheckinInterval = 20000
org.quartz.scheduler.jobFactory.class = org.quartz.simpl.SimpleJobFactory
org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX
org.quartz.jobStore.useProperties = false
org.quartz.jobStore.dataSource = QUARTZDS
org.quartz.jobStore.tablePrefix = QRTZ_
org.quartz.jobStore.isClustered = true
org.quartz.jobStore.driverDelegateClass =
org.quartz.impl.jdbcjobstore.PostgreSQLDelegate
org.quartz.dataSource.QUARTZDS.jndiURL=openejb:Resource/QUARTZDS
I'have a singleton with three method annotated similar to this:
@Schedule(second = "*/4", minute = "*", hour = "*", persistent = true)
public void printHello() {
System.out.println("printHello....." + new Date());
}
No other quartz specific configuration is applied.
If I fire up three servers, the servers are running one distinct
mtehod/process which is what I expect.
However, If I shut down one of the servers, no process is run on the remaing
ones.
Is this how its supposed to work?
The server first fired up in the cluster is showing:
INFO: ClusterManager: detected 1 failed or restarted instances.
des 15, 2013 6:28:42 PM org.quartz.impl.jdbcjobstore.JobStoreSupport
clusterRecover
INFO: ClusterManager: Scanning for instance "helge-ThinkPad1387128403117"'s
failed in-progress jobs.
My final goal is to have timer services evenly distributed in my cluster and
having all services run if one node fails.
Is this possible without using quartz specific implementation of jobs?
TomEE 1.6.0
best regards,
hw
--
View this message in context: http://openejb.979440.n4.nabble.com/TomEE-and-persistent-timers-tp4666750.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: TomEE and persistent timers
Posted by hwaastad <he...@waastad.org>.
Hi,
and thx for input!
Good call.
I've done so, but still I have an issue with the user/principal/context.
Right now I'm testing with remote ejb's which is working.
Don't know if this is something worth looking close at.
br,
hw
--
View this message in context: http://openejb.979440.n4.nabble.com/TomEE-and-persistent-timers-tp4666750p4666802.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: TomEE and persistent timers
Posted by AndyG <an...@orprovision.com>.
For a local context:
Get rid of Context.PROVIDER_URL and "openejb.ejbd.authenticate-with-request"
properties.
...and use Context.INITIAL_CONTEXT_FACTORY,
"org.apache.openejb.core.LocalInitialContextFactory" rather than
"org.apache.openejb.client.LocalInitialContextFactory"
Andy.
--
View this message in context: http://openejb.979440.n4.nabble.com/TomEE-and-persistent-timers-tp4666750p4666800.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: TomEE and persistent timers
Posted by Helge Waastad <he...@waastad.org>.
Hi, all part of my testing :-)
Well, I've updated the code.
exposing @remote and @local
Using remote:
props.put("java.naming.security.principal", "admin");
props.put("java.naming.security.credentials", "admin");
props.put(Context.INITIAL_CONTEXT_FACTORY,
"org.apache.openejb.client.RemoteInitialContextFactory");
props.put(Context.PROVIDER_URL, "http://127.0.0.1:8081/tomee/ejb");
BusinessBeanRemote businessBean = (BusinessBeanRemote)
ctx.lookup("BusinessBeanRemote");
All is well and BusinessBean prints out correct user (admin).
Using Local:
props.put(Context.INITIAL_CONTEXT_FACTORY,
"org.apache.openejb.client.LocalInitialContextFactory");
props.put(Context.PROVIDER_URL, "http://127.0.0.1:8081/tomee/ejb");
BusinessBeanLocal businessBean = (BusinessBeanLocal)
ctx.lookup(BusinessBeanLocal);
Businessbean = guest user.
If I add credentials to local lookup the login exception comes.
br
hw
ti., 17.12.2013 kl. 15.32 +0100, skrev Romain Manni-Bucau:
> Hmm
>
> Properties props = new Properties();
> props.put("java.naming.security.principal", "admin");
> props.put("java.naming.security.credentials", "admin");
> // props.put("Context.SECURITY_PRINCIPAL", "admin");
> // props.put("Context.SECURITY_CREDENTIALS", "admin");
> props.put("openejb.authentication.realmName", "PropertiesLogin");
> props.put("openejb.ejbd.authenticate-with-request", "true");
> props.put(Context.INITIAL_CONTEXT_FACTORY,
> "org.apache.openejb.client.LocalInitialContextFactory");
> props.put(Context.PROVIDER_URL, "http://127.0.0.1:8081/tomee/ejb");
>
> If you use LocalInitialContextFactory you don't need other props since
> that's a local lookup and you'll simply reuse the current context. Did you
> intend to use RemoteInitialContextFactory?
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau
> <http://fr.linkedin.com/in/rmannibucau>*
> *Github: https://github.com/rmannibucau <https://github.com/rmannibucau>*
>
>
>
> 2013/12/17 Helge Waastad <he...@waastad.org>
>
> > Sure, I'm happy to [image: :-)]
> >
> > Here's som testcode I've been testing.
> > there are 3 nodes for testing failover, but right now it's only node1
> > working (I think...)
> > https://github.com/hwaastad/QuartsApp.git
> >
> > runs on localhost:8081/QuartsApp
> >
> > user: admin/admin
> >
> > I guess you need quartz postgres db aswell.
> >
> > mvn tomee:run -Pnode1
> >
> > hw
> >
> >
> > ti., 17.12.2013 kl. 12.19 +0100, skrev Romain Manni-Bucau:
> >
> > Can you share some code please to fix ideas?
> > Romain Manni-Bucau
> > Twitter: @rmannibucau
> > Blog: http://rmannibucau.wordpress.com/
> > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > Github: https://github.com/rmannibucau
> >
> >
> >
> > 2013/12/17 hwaastad <he...@waastad.org>:
> > > Hi Romain,
> > > I'll try to be more specific:
> > >
> > > My job will call an EJB for processing data.
> > >
> > > The method called is secured by @rolesallowed and, as you say, jobs are'nt
> > > managed object. so I have to lookup the EJB.
> > > Right now I'm trying to add credentials via:
> > >
> > > props.put("java.naming.security.principal", "admin");
> > > props.put("java.naming.security.credentials", "admin");
> > > props.put("openejb.authentication.realmName", "PropertiesLogin");
> > > props.put("openejb.ejbd.authenticate-with-request", "true");
> > > props.put(Context.INITIAL_CONTEXT_FACTORY,
> > > "org.apache.openejb.client.LocalInitialContextFactory");
> > > props.put(Context.PROVIDER_URL, "http://127.0.0.1:8080/tomee/ejb");
> > >
> > > But now I get:
> > > javax.security.auth.login.LoginException: Thread already associated with a
> > > client identity. Refusing to overwrite.
> > >
> > > I'm maybe barking up the wrong tree here and maybe I'll have to redesign my
> > > older @schedule jobs to "unsecured" ejb's.
> > > As always: Work in Progress :-)
> > >
> > > br,
> > > hw
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > View this message in context: http://openejb.979440.n4.nabble.com/TomEE-and-persistent-timers-tp4666750p4666780.html
> > > Sent from the OpenEJB User mailing list archive at Nabble.com.
> >
> >
> >
Re: TomEE and persistent timers
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hmm
Properties props = new Properties();
props.put("java.naming.security.principal", "admin");
props.put("java.naming.security.credentials", "admin");
// props.put("Context.SECURITY_PRINCIPAL", "admin");
// props.put("Context.SECURITY_CREDENTIALS", "admin");
props.put("openejb.authentication.realmName", "PropertiesLogin");
props.put("openejb.ejbd.authenticate-with-request", "true");
props.put(Context.INITIAL_CONTEXT_FACTORY,
"org.apache.openejb.client.LocalInitialContextFactory");
props.put(Context.PROVIDER_URL, "http://127.0.0.1:8081/tomee/ejb");
If you use LocalInitialContextFactory you don't need other props since
that's a local lookup and you'll simply reuse the current context. Did you
intend to use RemoteInitialContextFactory?
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau
<http://fr.linkedin.com/in/rmannibucau>*
*Github: https://github.com/rmannibucau <https://github.com/rmannibucau>*
2013/12/17 Helge Waastad <he...@waastad.org>
> Sure, I'm happy to [image: :-)]
>
> Here's som testcode I've been testing.
> there are 3 nodes for testing failover, but right now it's only node1
> working (I think...)
> https://github.com/hwaastad/QuartsApp.git
>
> runs on localhost:8081/QuartsApp
>
> user: admin/admin
>
> I guess you need quartz postgres db aswell.
>
> mvn tomee:run -Pnode1
>
> hw
>
>
> ti., 17.12.2013 kl. 12.19 +0100, skrev Romain Manni-Bucau:
>
> Can you share some code please to fix ideas?
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2013/12/17 hwaastad <he...@waastad.org>:
> > Hi Romain,
> > I'll try to be more specific:
> >
> > My job will call an EJB for processing data.
> >
> > The method called is secured by @rolesallowed and, as you say, jobs are'nt
> > managed object. so I have to lookup the EJB.
> > Right now I'm trying to add credentials via:
> >
> > props.put("java.naming.security.principal", "admin");
> > props.put("java.naming.security.credentials", "admin");
> > props.put("openejb.authentication.realmName", "PropertiesLogin");
> > props.put("openejb.ejbd.authenticate-with-request", "true");
> > props.put(Context.INITIAL_CONTEXT_FACTORY,
> > "org.apache.openejb.client.LocalInitialContextFactory");
> > props.put(Context.PROVIDER_URL, "http://127.0.0.1:8080/tomee/ejb");
> >
> > But now I get:
> > javax.security.auth.login.LoginException: Thread already associated with a
> > client identity. Refusing to overwrite.
> >
> > I'm maybe barking up the wrong tree here and maybe I'll have to redesign my
> > older @schedule jobs to "unsecured" ejb's.
> > As always: Work in Progress :-)
> >
> > br,
> > hw
> >
> >
> >
> >
> >
> >
> >
> > --
> > View this message in context: http://openejb.979440.n4.nabble.com/TomEE-and-persistent-timers-tp4666750p4666780.html
> > Sent from the OpenEJB User mailing list archive at Nabble.com.
>
>
>
Re: TomEE and persistent timers
Posted by Helge Waastad <he...@waastad.org>.
Sure, I'm happy to :-)
Here's som testcode I've been testing.
there are 3 nodes for testing failover, but right now it's only node1
working (I think...)
https://github.com/hwaastad/QuartsApp.git
runs on localhost:8081/QuartsApp
user: admin/admin
I guess you need quartz postgres db aswell.
mvn tomee:run -Pnode1
hw
ti., 17.12.2013 kl. 12.19 +0100, skrev Romain Manni-Bucau:
> Can you share some code please to fix ideas?
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2013/12/17 hwaastad <he...@waastad.org>:
> > Hi Romain,
> > I'll try to be more specific:
> >
> > My job will call an EJB for processing data.
> >
> > The method called is secured by @rolesallowed and, as you say, jobs are'nt
> > managed object. so I have to lookup the EJB.
> > Right now I'm trying to add credentials via:
> >
> > props.put("java.naming.security.principal", "admin");
> > props.put("java.naming.security.credentials", "admin");
> > props.put("openejb.authentication.realmName", "PropertiesLogin");
> > props.put("openejb.ejbd.authenticate-with-request", "true");
> > props.put(Context.INITIAL_CONTEXT_FACTORY,
> > "org.apache.openejb.client.LocalInitialContextFactory");
> > props.put(Context.PROVIDER_URL, "http://127.0.0.1:8080/tomee/ejb");
> >
> > But now I get:
> > javax.security.auth.login.LoginException: Thread already associated with a
> > client identity. Refusing to overwrite.
> >
> > I'm maybe barking up the wrong tree here and maybe I'll have to redesign my
> > older @schedule jobs to "unsecured" ejb's.
> > As always: Work in Progress :-)
> >
> > br,
> > hw
> >
> >
> >
> >
> >
> >
> >
> > --
> > View this message in context: http://openejb.979440.n4.nabble.com/TomEE-and-persistent-timers-tp4666750p4666780.html
> > Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: TomEE and persistent timers
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Can you share some code please to fix ideas?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2013/12/17 hwaastad <he...@waastad.org>:
> Hi Romain,
> I'll try to be more specific:
>
> My job will call an EJB for processing data.
>
> The method called is secured by @rolesallowed and, as you say, jobs are'nt
> managed object. so I have to lookup the EJB.
> Right now I'm trying to add credentials via:
>
> props.put("java.naming.security.principal", "admin");
> props.put("java.naming.security.credentials", "admin");
> props.put("openejb.authentication.realmName", "PropertiesLogin");
> props.put("openejb.ejbd.authenticate-with-request", "true");
> props.put(Context.INITIAL_CONTEXT_FACTORY,
> "org.apache.openejb.client.LocalInitialContextFactory");
> props.put(Context.PROVIDER_URL, "http://127.0.0.1:8080/tomee/ejb");
>
> But now I get:
> javax.security.auth.login.LoginException: Thread already associated with a
> client identity. Refusing to overwrite.
>
> I'm maybe barking up the wrong tree here and maybe I'll have to redesign my
> older @schedule jobs to "unsecured" ejb's.
> As always: Work in Progress :-)
>
> br,
> hw
>
>
>
>
>
>
>
> --
> View this message in context: http://openejb.979440.n4.nabble.com/TomEE-and-persistent-timers-tp4666750p4666780.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: TomEE and persistent timers
Posted by hwaastad <he...@waastad.org>.
Hi Romain,
I'll try to be more specific:
My job will call an EJB for processing data.
The method called is secured by @rolesallowed and, as you say, jobs are'nt
managed object. so I have to lookup the EJB.
Right now I'm trying to add credentials via:
props.put("java.naming.security.principal", "admin");
props.put("java.naming.security.credentials", "admin");
props.put("openejb.authentication.realmName", "PropertiesLogin");
props.put("openejb.ejbd.authenticate-with-request", "true");
props.put(Context.INITIAL_CONTEXT_FACTORY,
"org.apache.openejb.client.LocalInitialContextFactory");
props.put(Context.PROVIDER_URL, "http://127.0.0.1:8080/tomee/ejb");
But now I get:
javax.security.auth.login.LoginException: Thread already associated with a
client identity. Refusing to overwrite.
I'm maybe barking up the wrong tree here and maybe I'll have to redesign my
older @schedule jobs to "unsecured" ejb's.
As always: Work in Progress :-)
br,
hw
--
View this message in context: http://openejb.979440.n4.nabble.com/TomEE-and-persistent-timers-tp4666750p4666780.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: TomEE and persistent timers
Posted by Romain Manni-Bucau <rm...@gmail.com>.
sorry don't follow you.
Quartz jobs are not managed object, only internals.
SessionContext should be propagated from where? from jobs? same note applies
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2013/12/16 hwaastad <he...@waastad.org>:
> OK,
> i've read some of the discussions on the dev list. Interesting.
>
> BTW,
> I realized that Injection (@EJB/@Inject) does not work in Quartz jobs so I
> have to lookup my ejb's.
> But my next problem is that my service EJB's (which are called by the job)
> are protected by @rolesallowed.
>
> I've tried do let my jobs be stateless but it seems that sessioncontext is
> not progated.
>
> Is there a workaround for this issue? If not, I probably have to look into
> redesigning my lookups (adding credentials props etc)
>
> br hw
>
>
>
> --
> View this message in context: http://openejb.979440.n4.nabble.com/TomEE-and-persistent-timers-tp4666750p4666776.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: TomEE and persistent timers
Posted by hwaastad <he...@waastad.org>.
OK,
i've read some of the discussions on the dev list. Interesting.
BTW,
I realized that Injection (@EJB/@Inject) does not work in Quartz jobs so I
have to lookup my ejb's.
But my next problem is that my service EJB's (which are called by the job)
are protected by @rolesallowed.
I've tried do let my jobs be stateless but it seems that sessioncontext is
not progated.
Is there a workaround for this issue? If not, I probably have to look into
redesigning my lookups (adding credentials props etc)
br hw
--
View this message in context: http://openejb.979440.n4.nabble.com/TomEE-and-persistent-timers-tp4666750p4666776.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: TomEE and persistent timers
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi
Yes (that's how tomee does btw)
Side note: next release will shade quartz so org.quartz.* will become
org.apache.openejb.quartz.*
Le 16 déc. 2013 11:42, "hwaastad" <he...@waastad.org> a écrit :
> Hi,
> yes it's the same database.
>
>
> Well, you're probably right.
> I moved my scheduling completely over to use quartz
> configuration/initializing and I get the failover/persistency I need for
> clustering.
>
> BTW,
> I've read that the application.properties including quartz properties is
> supposed to be put in WEB-INF (for war).
>
> I was actually hoping I could use StdSchedulerFactory.getDefaultScheduler()
> but this always returns default RAMJobStore so I have to initialize factory
> with props.
> Again, is this how it's supposed to be?
>
> br,
> hw
>
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/TomEE-and-persistent-timers-tp4666750p4666754.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
Re: TomEE and persistent timers
Posted by hwaastad <he...@waastad.org>.
Hi,
yes it's the same database.
Well, you're probably right.
I moved my scheduling completely over to use quartz
configuration/initializing and I get the failover/persistency I need for
clustering.
BTW,
I've read that the application.properties including quartz properties is
supposed to be put in WEB-INF (for war).
I was actually hoping I could use StdSchedulerFactory.getDefaultScheduler()
but this always returns default RAMJobStore so I have to initialize factory
with props.
Again, is this how it's supposed to be?
br,
hw
--
View this message in context: http://openejb.979440.n4.nabble.com/TomEE-and-persistent-timers-tp4666750p4666754.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: TomEE and persistent timers
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi
are you sure you share the same db between all servers?
That said I think it only works in failover mode if you don't
implement a custom TimerStore (openejb) since default is in memory
(load from persistence at startup).
Finally does it makes really sense if all instances have their own
@Schedule? If yes it means you don't care of @Schedule config since
you support timeout trigerring on a single node from multiple nodes so
maybe not the right tool.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2013/12/15 hwaastad <he...@waastad.org>:
> Hi,
> until now I've just used standard config for my @schedule processes.
> However in my quest for clustered setup I've started to look into persistent
> storage for quartz.
>
> Now, I'm quite new to quartz so I might be missing out on something so I
> hope you can bear with me :-)
>
> application.properties:
>
> org.quartz.scheduler.skipUpdateCheck = true
> org.quartz.scheduler.instanceName = TestScheduler
> org.quartz.scheduler.instanceId = AUTO
> org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool
> org.quartz.threadPool.threadCount = 5
> #org.quartz.threadPool.threadPriority = 5
> #org.quartz.jobStore.misfireThreshold = 60000
> #org.quartz.jobStore.clusterCheckinInterval = 20000
> org.quartz.scheduler.jobFactory.class = org.quartz.simpl.SimpleJobFactory
> org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX
> org.quartz.jobStore.useProperties = false
> org.quartz.jobStore.dataSource = QUARTZDS
> org.quartz.jobStore.tablePrefix = QRTZ_
> org.quartz.jobStore.isClustered = true
> org.quartz.jobStore.driverDelegateClass =
> org.quartz.impl.jdbcjobstore.PostgreSQLDelegate
> org.quartz.dataSource.QUARTZDS.jndiURL=openejb:Resource/QUARTZDS
>
>
> I'have a singleton with three method annotated similar to this:
>
> @Schedule(second = "*/4", minute = "*", hour = "*", persistent = true)
> public void printHello() {
> System.out.println("printHello....." + new Date());
> }
>
> No other quartz specific configuration is applied.
>
> If I fire up three servers, the servers are running one distinct
> mtehod/process which is what I expect.
> However, If I shut down one of the servers, no process is run on the remaing
> ones.
> Is this how its supposed to work?
> The server first fired up in the cluster is showing:
> INFO: ClusterManager: detected 1 failed or restarted instances.
> des 15, 2013 6:28:42 PM org.quartz.impl.jdbcjobstore.JobStoreSupport
> clusterRecover
> INFO: ClusterManager: Scanning for instance "helge-ThinkPad1387128403117"'s
> failed in-progress jobs.
>
>
> My final goal is to have timer services evenly distributed in my cluster and
> having all services run if one node fails.
> Is this possible without using quartz specific implementation of jobs?
>
> TomEE 1.6.0
> best regards,
> hw
>
>
>
> --
> View this message in context: http://openejb.979440.n4.nabble.com/TomEE-and-persistent-timers-tp4666750.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.