A few weeks ago we developed an EJB 3.0 TimerService to schedule some tasks on demand (when the user clicked a button, we would create the timer to perform some tasks). So far it's been working well, until today.
Yesterday we redeployed the EJB containing de TimerService to update some properties, and today no timers were fired, even though there were some created.
¿Is this normal? I mean, if you don't change the signature of the ejbTimeOut, shouldn't it launch as always after a redeploy?
To make a timer persistent use the TimerHandle as explained here:
To save a Timer object for future reference, invoke its getHandle method and store the TimerHandle object in a database. (A TimerHandle object is serializable.) To re-instantiate the Timer object, retrieve the handle from the database and invoke getTimer on the handle. A TimerHandle object cannot be passed as an argument of a method defined in a remote or web service interface. In other words, remote clients and web service clients cannot access a bean’s TimerHandle object. Local clients, however, do not have this restriction.
Taken from http://docs.oracle.com/javaee/5/tutorial/doc/bnboy.html
Timers are persistent by default. When you restart server, redeploy application etc. probably if they were missed out, will timeout.
I have faced similar issues in the past. Therefore it's advisable to cancel all previous existing timers & then create new one afterwards.
That's the behavior in EJB 3.0. In EJB 3.1, timer service becomes much better. It supports automatic timer, which is created upon successful deployment. You may want to see if upgrading to EJB 3.1 is an option for you.
EE6 Tutorial: Using Timer Service
Enterprise bean timers are either programmatic timers or automatic
timers. Programmatic timers are set by explicitly calling one of the
timer creation methods of the TimerService interface. Automatic timers
are created upon the successful deployment of an enterprise bean that
contains a method annotated with the java.ejb.Schedule or
java.ejb.Schedules annotations.
Use asadmin redeploy command with --keepstate flag equals to true.
Full example:
asadmin redeploy --keepstate=true --name=taskee-1.0-SNAPSHOT target/taskee-1.0-SNAPSHOT.war
More info in:
http://www.oracle.com/technetwork/articles/java/pongegf-1517943.html
Related
I try all the possible configuration in ClickOnce but the application only updates on restart.
I want the application to update after the application startup but in VS 2022 the update after startup is blocked as we can see in the following image:
I am using .net core 6 and my IDE is VS2022.
According to the documentations, checking for update before the application starts, is the default and only option available for .NET 3.1 and newer versions:
For .NET 3.1 and newer applications, checking updates before the application starts is the only update option supported.
ClickOnce update strategies
Here is a summary of main ClickOnce update strategies:
Automatic update - Check for updates after application startup
In this strategy, ClickOnce will check updates in the background when the application starts. Then, the next time when the user starts the application, based on the result of previous check-for-update, if an update was available, it shows a prompt to the user asking to download and install the updates.
Main use-case for this scenario is low-bandwidth networks or large applications when updates takes longer to download and install.
Automatic update - Check for updates before application startup
In this strategy, every time the user starts the application, the application first checks for an update and if an update is available, it downloads and applies the updates and then start the application.
It's the default strategy and as I mentioned above, it's the only available option for .NET 3.1 and above.
Main use-case for this scenario is high-bandwidth networks and also cases which you want to make the update mandatory.
Manual update - Provide a user interface for updates
In this strategy, developer writes code using the ApplicationDeployment class to check for updates; For example checking for update based on when users clicks on a menu item or button; or based on a custom user-defined schedule.
The main usage scenario for this strategy is when you want to have different strategies for different users, or custom scheduled updates for different users, or to have a manual check for update button/menu.
To learn more, take a look at the following doc articles:
Choose a ClickOnce update strategy
How ClickOnce performs application updates
How to: Check for application updates programmatically using the ClickOnce deployment API
We have a service running on Google App Engine.
If that service does not receive a traffic for some time then all instances are killed and the next call takes a few additional seconds to start the application.
We are thinking about specifying a min_instances option in app.yaml to always keep at least one instance alive.
We deploy new versions of that service quite frequently and keeping old versions for some time. Those old versions are not serving traffic and kept just in case.
What we would like to do is to always keep at least one instance of default service version alive and leave all other non-default versions with default behavior – we want them to be scaled automatically to 0 instances if they do not receive any traffic.
I didn't find such option in the documentation (https://cloud.google.com/appengine/docs/standard/python3/config/appref#scaling_elements) and didn't come to any workarounds.
I am thinking about creating a cron job (https://cloud.google.com/appengine/docs/flexible/python/scheduling-jobs-with-cron-yaml) which will periodically "ping" only default version of my application periodically thus making it always asleep. But I am not sure if it is good solution.
Are there any better solutions to such case?
Thanks!
min_idle_instances config option seems to solve my problem.
Note following in the documentation: "This setting only applies to the version that receives most of the traffic" which is almost exactly my case:
automatic_scaling:
min_idle_instances: 1
While trying to call RPC method of another agent (pricepoint.agent) from one of my agent( smartstripui_srv.agent), there is an error - " INFO: 'SmartStripUI_Srv' object has no attribute 'vip'"
smartstripui_srv.agent is inheriting PublishMixin, BaseAgent.
I had tested calling RPC method of pricepoint.agent from a simple Agent and it is working.
In the case of an agent inheriting PublishMixin, BaseAgent, it seems that I might be missing setting some parameter.
PublishMixin and BaseAgent and everything else in volttron.platform.agent.base are for supporting backwards compatibility with VOLTTRON 2.0 Agents.
Don’t use them.
Inheriting from volttron.platform.vip.agent.Agent will give you everything you need to publish, subscribe, and do RPC calls and take full advantage of VOLTTRON 3.0 features and will make available the vip object in your agent.
Unfortunately we failed to move everything that was not for backward compatibility out of volttron.platform.agent when we released VOLTTRON 3.0. There are things in there that are still vital to 3.0 Agents such as the utils module.
I am interesting in hearing if others have addressed release management for Silverlight applications.
I have a business application that is to be released shortly andam concerned about how to "release" updates to this application. Typically this application's users will leave the application open all day (and potentially all night) without reloading it.
What if there is is need to release an change that includes an web service interface change? How can this be deployed w/o causing errors on the client side?
We have grown so used to deploying ASP.Net apps by just dropping the latest code on the server. My only idea currently involves a client version number and a periodic timer on to check for updates.
I would love to know what others have done before implementing this.
Thanks,
Mike
I just answered a question on how to make sure that .xap files are not cached by the browser, which might be of some help:
Prevent Silverlight xap from being cached by proxy server
But that's no use if the users never reload your application. In my own application this is not a problem since users will be automatically thrown out whenever we deploy an update to the web service. But I like your idea with the timer, I would go with that.
Stating the obvious but don't do anything to annoy your users. E.g. could they spend twenty minutes entering data, nip off to the coffee machine and return to click Submit to find the timer has expired, noticed an update and their work is lost due to a forced restart?
If so, and I admit this hasn't had a lot of thought, if e.g. you have to make changes to the web service that break the current release, could you have the new web service version side-by-side such that users don't get thrown out until the timer has expired and the unit of work is complete? Or is this also stating the obvious?
For server code, i.e. endpoints just do as per normal. for the xap's I think you have a few options depending upon how you handle communications. You could have request contain a version number and if the server has been updated then force some code to reload the client, bit lame, messy but do-able. Perhaps a cleaner solution would be to control the clients session, which presumably is part and parcel with requests to the backedn. When you deploy a new version you could invalidate the client session, perhaps forcing a page refresh with custom logic. If your protocol is push base you could send a command to the client to do what ever you want, for many systems that are on all day its likely that this infrastructure would exist (if u've build it nicely :)). For instance our service layer is abstracted away from the repositories models and view models, in our case we'd could send a logout or perhaps a specific command to kick in some custom logic on the client informing the application is being updated and to refresh your browser when done. Our shell is light weight so our modules (basically other xap's) can be updated in time for the refresh.
I would recommend you to use a solution like mentioned in App Arch Guide:
The Guide Chapter I mean see Deployment considerations.
Divide the application into logical
modules that can be cached
separately, and that can be replaced
easily without requiring the user to
download the entire application
again.
Version your components.
Have you considered keeping a WCF polling duplex channel going that alerts the app when it needs to reload? In addition, you can have your WCF calls direct to a virtual directory that contains 'interfaced' calls. For example:
Silverlight app hosted at "x.x.x.x\Default.aspx"
Silverlight talks to WCF at "x.x.x.x\Version2\DataPortal.svc"
DataPortal.svc talks to a GAC (or otherwise base) assembly that can identify what version can handle what calls.
This way, if you upgrade to "x.x.x.x\Version3\DataPortal.svc", you can still make calls against Version2, assuming those calls have code to convert them to a Version3 concept.
This helps in cases where your line of business app has dynamic xap downloading ('main', 'customer', 'inventory', etc.) and you want to release them independently.
I am creating a Silverlight 2 user interface to a remote instrument. There are two concurrent users at different sites interacting with the instrument (operator at the instrument and remote scientist) and any number of observer users not interacting with it, just watching. However, whenever one of the two active users changes something these changes must be immediately reflected in the UIs of all users, e.g. panning or zooming an image or annotating or selecting part of an image, adding items to a collection displayed in a listbox. Within the client I use observable collections which easily reflect changes made by that user, but it is harder seeing changes made by another user. I can poll for changes from each client but something like push notifications would be better. I have extensively Googled for examples but not found anything which is quite what I need. There are all sorts of security issues with Silverlight interacting with WCF services which mean many potential examples just don't work. I have essentially run out of time on this project and need help fast. Does anyone have any suggestion of a suitable simple example which illustrates how to do this? I am an experienced developer but have had to teach myself Silverlight and WCF services and there is noone in my area who knows anything about these. Even tho' I have done a fair amount of ASP.NET work I am not a web/Javascript guru. Thanks.
Push notification is supported in Silverlight 2 using the new WCF PollingDuplexHttpBinding support. There are two assemblies installed with the Silverlight SDK (one for Silverlight app one for WCF server).
I have a few blog posts and a full sample application that demonstrate how to 'push' Stock updates from a Console Application server that self-hosts a WCF service to connected clients. It also shows how each client can add notes against a Stock and have those notes synchronized (pushed from server) to all other connected clients.
The latest version of the sample (Part 4) shows how to synchronize pushed updates between both Silverlight and WPF clients using two server endpoints as follows:
using System;
using System.ServiceModel;
using System.ServiceModel.Description;
namespace StockServer
{
public class StockServiceHost : ServiceHost
{
public StockServiceHost(object singletonInstance, params Uri[] baseAddresses)
: base(singletonInstance, baseAddresses)
{
}
public StockServiceHost(Type serviceType, params Uri[] baseAddresses)
: base(serviceType, baseAddresses)
{
}
protected override void InitializeRuntime()
{
this.AddServiceEndpoint(
typeof(IPolicyProvider),
new WebHttpBinding(),
new Uri("http://localhost:10201/")).Behaviors.Add(new WebHttpBehavior());
this.AddServiceEndpoint(
typeof(IStockService),
new PollingDuplexHttpBinding(),
new Uri("http://localhost:10201/SilverlightStockService"));
this.AddServiceEndpoint(
typeof(IStockService),
new WSDualHttpBinding(WSDualHttpSecurityMode.None),
new Uri("http://localhost:10201/WpfStockService"));
base.InitializeRuntime();
}
}
}
WPF clients connect to the WSDualHttpBinding endpoint and Silverlight clients connect to the PollingDuplexHttpBinding endpoint of the same WCF service. The app also shows how to handle the Silverlight client access policy requirements.
Clients (Silverlight or WPF) can add notes against a Stock in their UI and these notes propagate back to the server to be pushed to all other clients. This demonstrates communication in either direction and hopefully performs all of the necessary communication required for your app.
You can see a screenshot of the demo application running here.
Not that am pushing Flex in fan boy fashion, but matter of factly this is the kind of architecture we build into all our Flex-based applications routinely. Here is what we do on Flex - no doubt it could be suitably translated to Silverlight:
We take three ingredients and integrate them together to accomplish this capability:
Comet pattern (an HTTP compatible way to do server push notifications - look on Wikipedia for more info)
JMS messaging topics (publish/subscriber queues)
The Adobe BlazeDS servlet
The latter item implements the Comet pattern, supports AMF object marshaling (Adobe's binary serialization format for ActionScript3 objects), and bridges to a JMS queue or topic. When bridging to a topic, then multiple Flex clients running in a browser can be proxied in as subscribers to a JMS topic. So if any client publishes a message (or the server-side code publishes into the topic), all client subscribers will have the message pushed to them via BlazeDS and the Comet Pattern implementation.
Effectively you need to locate or write a component that accomplishes what BlazeDS does. You might also need to implement some client code that interacts with the Comet pattern of this server-side component.
Does WCF support the Comet Pattern and bi-directional messaging? Especially where complies to HTTP and port 80 or port 443 for SSL. Looks like you've already looked into that and not found anything for bi-directional messaging. So you may need to roll your sleeves up and do some coding.
Some things to note about doing server push to a web app:
BlazeDS supports two primary modes of implementing the Comet pattern (there's actually a 3rd polling option but am ignoring it):
long-polling
HTTP streaming
The long-polling one you should find to be more universally supportable to most web browsers. So you might streamline to just supporting that initially. Or you could spend the time to make your client code try HTTP streaming first and switch to long-polling if necessary.
As to a message broker that can provide publish/suscribe capatibility, you might consider using ActiveMQ JMS. It is open source and free with active community support (you can buy support too). Plus you can use NMS to integrate as a .NET client.
Having a message broker sitting in the middle-tier is actually important because it will be a place for messages to be placed safely. If your clients are doing long-polling, you wouldn't want them to miss any new message during an interval when they're not actually connected.
Another thing to consider in high traffic volume scenarios (hundreds or thousands of clients, such as a web site on the Internet), you need to have an approach to the Comet Pattern that is scalable.
In the Flex/Java world, the BlazeDS servlet (which is open source) has been modified to work with asynchronous model. In Java a socket listener can be built to use NIO channels and Java Concurrency Executor thread pools. The Tomcat web server has a NIO listener and support for asynchronous Servlet 3.0 events. BlazeDS in particular has been modified, though, to work with the Jetty web server. The bottom line is that the scalability of this asynchronous approach means a single physical web server can be enhanced to support up to around 20,000 concurrent Comet-style client connections.
It's been a while since I've done serious .NET programming but used to the io capabilities were much like Java 1.1 except with an asynchronous result handler capability. This, though, is not the same thing as creating asynchronous socket listeners via Java NIO channels. A NIO channel implementation can support hundreds to thousands of socket connections with a relatively small thread pool. But C# and .NET has gone through two or three significant revs - perhaps there have been new io capabilities added that are comparable to NIO channels.
I just wanted to clarify that the PollingDuplexHttpBinding doesn't implement 'true' push notifications, as reveals its name (polling). From the msdn documentation:
When configured with this binding, the Silverlight client periodically polls the service on the network layer, and checks for any new messages that the service wants to send on the callback channel. The service queues all messages sent on the client callback channel and delivers them to the client when the client polls the service.
However it is more efficient than the traditional way of polling a web service, since after each poll, the server will keep the channel open for a certain time (say 1 minute), and if a message arrives in that time it will directly 'push' the message to the client. The client has to repeatedly renew its connection, it so to say polls the service.
If you want to implement real push notifications with silverlight I believe you need to work with sockets, and I recommend reading some of Dan Wahlin's blog posts on the subject.
Alternatively,
if you want a native silverlight API with no proxies, bridges or webservers involved you could use Nirvana from my-Channels as your messaging middleware. Check out Nirvana from my-Channels and their showcase site. (sorry i am a new user and cant submit links):
Alex
EDIT: it's actually working fine. I got badly bitten by the "hidden variable" in a closure :(
I used the PollingDuplex for SL2 and I think that it's not ready for production yet.
My main issue is the fact that it doesn't discriminate on the clients on the same machine. If I run 2 clients then one of them won't be able to poll the server anymore and will die of timeout. There is a SessionId that is different for the 2 clients but it's just ignored on the client side.
Likewise, if I kill a client and then create a new one afterwards then the new client will get the push updates from the previous client for a while.
Did anyone encounter the same issues or are they fixed in SL3?
Actually I ran some more demo codes and realised that for some reason you have to specify the InstanceContextMode and InstanceMode so that the service is session based and not a singleton (as far as I can tell). There are clear performance issues in the simple demo code that I pulled.
It is quite unfortunate that this behaviour wasn't documented.
My organization found the Silverlight 2.0/WCF push implementation to be a little "not ready for prime time", at least for what we were planning to use it for.
We ended up going with XMPP/Jabber, because it is a more well formed beast, and you can implement it fairly easily in Silverlight, by just getting some resources off the internet.
I do believe that Silverlight 3.0 will implement a newer/more well formed push implementation, from what I can tell from publicly available information.
The PollingDuplexHttpBinding is probably the most elegant way to do it.
One possilby less involved alternative is to use a TCP socket from your Silverlight client. Whenever one of the Silverlight clients needs to have an update pushed you can send it a TCP message which contains the name of the WCF service it needs to call or some other light weight piece of information.
I use this approach for an application and it works well.
One much simpler and more powerful solution at the site http://www.udaparts.com/document/Tutorial/slpush.htm