I have created a scheduler using EJB 3.1 timee and schedulerd to execute at 22:30pm on week days. The annotation is given below:
#Schedule(minute="30", hour="22", dayOfWeek="5–1")
But I found that this scheduler executed immediately after starting the wildfly application server even if it is not the scheduled time.
Thanks!
I do not know exact circumstances when your server is restarted, but in case when e.g. server is shut down at 22.20 and started up at 22.35 then container is obliged to fire callback method for persistent timers after restart. As specification says (18.4.3):
Any interval persistent timers or schedule based persistent timers that have expired during the intervening time must cause the corresponding timeout callback method to be invoked at least once upon restart.
You use persistent timer so server restart during timer expiration could be the root cause of execution callback immediately after start up.
Related
On a celery service on CENTOS which runs a single task at a time, the termination of a task is simple:
revoke(id, terminate=True, signal='SIGINT')
However while the interrupt signal is being processed, the running task gets revoked. Then a new task - from the queue - starts on the node. This is troublesome. Two task are running at the same time on the node. The signal handling could take up to a minute.
The question is how a signal could be sent to a running task, without actually terminating the task in celery?
Or let's say is there any way to send a signal to a running task?
The assumption is user should be able to send a signal from a remote node. In other words user does not have access to list the running processes of the node.
Any other solution is welcome.
I don't understand your goal.
Are you trying to kill the worker? if so, I guess you are talking about t "Warm shutdown", so you can send the SIGTEERM to the worker's process. The running task will get a chance to finish but no new task will be added.
If you're just interested in revoking a specific task and keep using the same worker, can you share your celery configuration and the worker command? are you sure you're running with concurrency 1 ?
I have an X-code app integrated with Mobile first platform 7.0. I want to implement idle session timeout for the app. I have tried two scenarios to resolve this issue.
First I have added below line in server.xml
<httpSession invalidationTimeout="10m" />
Second I have added below line in worklight.properties
serverSessionTimeout=10
I am still not getting time out after being idle for more than 10 mins.
What am I missing?
The serverSessionTimeout property is a server property. Meaning that the session expires in the server and if the client attempts to connect to the server after the set expiration time, then the client will act accordingly.
If you have a security challenge in place, then once the expiration took place, the challenge would've been invoked (once the client attempts to connect the server). Otherwise, you cannot detect this through this property.
What you can do, is set a "timer" on the client side that runs and counts until the session time has met, and do some logic based on it. This of course solely depends on what your required scenario is.
I have to implement long running process which is starts via request to the wcf method (not start proces when application start)
I now that this is wrong solution, better will be windows serwis or something else for long running process, but for my situation it is impossible. I have to use wcf servis hosted on IIS.
I read about appdomain recycled and I can't figure out thing about Idle Timeout - appdomain restart if request run over 20 minutes. I know that this issue appears when is started background task in application start.
So will be my appdomain kill when (idle timeout is setup 20 minutes).
it is start one long running request, and after that will be not another request.
When process is started in application start IIS nothing knows about this task and this is for me clear that in this situation appdomain is closed
Does after 20 minutes IIS kill appdomain, besides that eier request still running ? I am confused, because IIS know about still running request and mayby does not do this.
What is true ?
Yes, IIS will kill the process because it works on a rolling horizon of requests, not what is running. A way around this might be to have the web service request itself while it is running to continually ping the server to let it know that it is still running. But on the whole, IIS will kill its processes when no requests are coming in.
Taken directly from MSDN: The worker process shuts down after it finishes processing its existing requests, or after a configured time-out, whichever comes first.
In your case, if your process is longer than the timeout, your process will never finish.
I have added the serverSessionTimeout=3 in the worklight properties file, I have edited this in the WAS server and restarted the application, but when i test the app and keep it idle for 3 mins, i cant see the server session time out automatically, is there anything we need to call on the mobile client to check if the server session time out is done or not. please help
Thanks
djrecker
Please look at the following documentation to get a better understanding of how the serverSessionTimeout and heartbeat property effect eachother as well as other tuning mechanisms:
http://pic.dhe.ibm.com/infocenter/wrklight/v6r0m0/index.jsp?topic=%2Fcom.ibm.worklight.help.doc%2Fadmin%2Fc_optimizing_and_tuning_of_ibm_wl_server.html
Specifically the "Worklight Server internal configuration" section:
"Consider the following factors:
A session is an object that is stored in server memory for each connecting device. Among other things, it stores authentication information. The number of active sessions is the difference between the number of opened sessions and the number of sessions that are timing out because of inactivity. The serverSessionTimeout property configures the session timeout and affects the server memory consumption. The default session timeout is 10 minutes.
The mobile client "heartbeat" property causes the mobile client to ping the server while the app is in the foreground. This feature prevents the server session from timing out.
When a mobile app runs in the background, it no longer interacts with the server or sends a “heartbeat”. The server session drops after the specified server session timeout period.
For example, suppose every minute 1,000 users start a session against the server. Even if they exit the application after 3 minutes, their sessions remain active on the server for 10 minutes, leaving 10 x 1,000 = 10,000 active sessions.
"
You could try disabling the heartbeat using
WL.Client.setHeartBeatInterval(-1)
Maybe during the initialization of your app
Documentation at:
http://pic.dhe.ibm.com/infocenter/wrklight/v6r0m0/index.jsp?topic=%2Fcom.ibm.worklight.help.doc%2Fapiref%2Fr_wl_client_setheartbeatinterval.html
With that the session timeout may work with the app in foreground too.
If the app is in the foreground, a heartbeat message will be sent
to the server and the session will not time out.
So the app should be placed in the background for the timeout to occur.
If that does not help, please try the test for a period of 10 minutes,
as this is the default session timeout value.
Normally the value of the serverSessionTimeout is greater than the
heartbeat interval so that the session is kept alive when idle and
as long as the application is in the foreground.
So as long as the app is in the foregraound,
by design it will never invalidate the session.
But on the other hand, if it is backgrounded then there are no heartbeats
and then past the default 10 min in the background state, the session
is invalidated. This is the intention here.
I have a WCF service that needs to get called so that the call will trigger a 2-3 hour of processing. I'm using windows C# client application to call the service and have set the timeouts to all the max values. When I deployed this to Windows Azure, the WCF process that was triggered by the client seems to stop after a certain moment. The client doesn't get the timeout exceptions. I can use Azure Worker Role, but the process can only be completed using only the WCF code because it is a complicated operation. In other words I can't just schedule Worker Role that executes a simple edit/insert operation to a database. So I kind of have a chicken and egg problem. The background process needs the WCF code to do the background operation, but the WCF seems to stop after a certain while on Azure. What is a way to execute a long running call in WCF and plus how to execute a long running call on Azure that needs to use the hosted cloud service WCF code to do the long running operation?
This is because of the load balancer. The timeout used to be 60 seconds, but a few months ago this was increased to 'more than 60 seconds' (depending on the concurrent connections). Anyways, you need to keep the connection alive in order to avoid the timeout.
I suggest you try implementing this in your WCF client/service: WCF Azure Net.TCP Keep Alive
Why not rethink your architecture? Instead of depending on a connection (that can be disconnected for whatever reason), why not simply have your client drop a message in a queue? Your worker role picks up the message from the queue, does the 2-3 hour processing and once it's done it drops a message in another queue. Finally your client polls that other queue and once a message arrives there it knows the process is complete.
You can place the code required for the long running operation in a seperate project. You can then include this project in your WCF solution and your Worker Role Solution.
The background process will then have all the functionality that it requires to complete the operation.