I'm working on a project where we use Flex, Spring, Hibernate and Blazeds, all working on a Weblogic server.
Everything works fine and we call services at the server side from the flex app without problems, but now we need to limit the time who spent the execution of the services to 2 seconds, if any service takes more than 2 seconds the server must return a timeout to the flex app.
I've been searching for a way to do this with the blazeds configuration, but it looks that it's not possible.
¿Is there any way to achieve this? I've thought in add a filter to the blazeds requests so it can control the timeout... But I can't find any example and I don't have enough knowledge of filters.
¿Could you help me with this problem?
Thanks.
I think you can set the timeout on RemoteObject OR Webservice.. whatever you are using. Once the specified timeout happens, it will throw a FaultEvent, which is when you supposed to take an appropriate action like for RemoteObject's use their channel's disconnect and so..
Look at this post:
Flex RemoteObject timeouts?
Related
I've joined a project that uses Jax-RS (and originally there was quite a bit of Spring-based Controller code in there too, but all URL handlers use Jax-RS now). Now we want to be able to fill in a queue of tasks that should be run with a small delay between each of them. The delay can be specified in ms. I've avoided Thread.sleep, as I've heard you should not manage threads manually in Java EE. Before I came in there was already a busy wait loop implemented.
I would like to switch this to an asynchronous background task. I could of course let the client poll the server with the given delay, and just have an AsyncResponse that can be resumed. But can the same AsyncResponse be resumed/suspended multiple times? The resource does have state, so it would be possible to drop the asynchrony completely and just do client polling to handle all of it.
A lot of example code for showing off asynchronous tasks use Thread.sleep. How bad is it to do this in a background task on an ExecutorService or something similar?
The point of the delay is to simulate human interaction, and post a long list of JMS messages to a queue but ensure that two listeners don't pick up and handle messages that depend on one another.
Is it easier/better to handle this on the client side rather than the server side? Writing some JavaScript that handles all the polling would be quite simple, so if this seems like a bad idea for handling on the server side, it's not that big a deal.
The tool is only going to be used by a single user, as it's a developer testing tool. Therefore we went for solving this on the client side, pushing the messages onto the queue through AJAX calls. This works fine for our purposes, but if anyone has a solution that might help someone else. Feel free to drop a new answer.
I have a process which I will be invoking manually for the first time in prod environment. Thing is, the process stops when the server is down or if the server is stopped. In this scenario, I will not be able to invoke the process manually everytime since it will be in production environment and not feasible also. So i need to know how can i invoke a process automatically once the server is up?
Heard that one way is to write a custom component to start the process using livecycle implementation class.
Please let me know how to go about it?
Any help regarding this is much appreciated!
Thanks
There are at least two ways you can do this.
First is the custom component route. You invoke the process on component life-cycle start to ensure that the invocation happens every time your component is deployed.
Second is the servlet route. You invoke the process on the initialisation of the servlet making sure that the server started.
The servlet implementation is a better fit for purpose, the only downside is, you need to package and deploy it separately as it won't be a part of the LCAs.
You can find the code samples on how to invoke LC processes using APIs on adobe docs. You can use Java API, WS API or Rest, whichever you are more comfortable with.
http://help.adobe.com/en_US/livecycle/9.0/programLC/help/index.htm
I have a web service that executes a task that may take hours to finish (asynchronously)
I would like to share the status of that task by all the clients that connects to the server (I'm using a web application for this)
For example, the first client that calls the page http://localhost/process.aspx
will instantiate the web service and it will call a method to start executing the task. A percentage number will be displayed showing the status of completion. I can do this by polling the web service using AJAX.
If there is another client that tries to opens that page, it should get the same percentage information so no new instances of the web service are created.
How is the best way of doing this?
I thought about different solutions but sooner or later I find new problems.
These are some of the possible alternatives:
Create an static object of the Web service.
Create the object in the global.asax file.
Do you guys have any other ideas? I'm not too familiar designing web sites and this is driving me crazy. I would appreciate if you guys could provide some code snippets.
Thanks
The issue is ensuring that the information pertaining to the single instance of a process is stored in exactly one place.
Your initial thinking can be applied, for instance, by using the Application object, but that will break down in a clustered IIS scenario.
I am not posative that a database is the absolute best solution, but I believe it would give you what you want.
If 100 clients try to start the process at the same time, only one can succeed, right? The databases locking facility will help you make that happen.
There's a method (I'm assuming WCF for the web service) that allows you to have exactly one instance of the service run... link
I think this is what you are trying to accomplish.
Assuming I have understood your requirements correctly. Your webservice should not be creating the instance of the “worker” object.
Your webservice request should log to either a database (as the other poster noted) or a messagequeue of somesort. At this point your “worker” processer (probably some type of service) should take over the job as it requires.
Basically you want to break up your application into something like this
| Webservice | ---------- | Datastore |-----------| Worker |
Any further requests regarding the batch should be managed by the webservice querying the datastore.
Remember webservices are NOT DESIGNED TO DO WORK.
How do you capture errors that happen on client side when building RIA apps using Flex and Silverlight? What are the common practices? I have seen some asynch js calls to a web service implemented but would like to know how the community is dealing with it.
First, I use client side logging all of the times.
the way I handle it depends on the entire application.
if I use an AMF gateway then there's a call for an application error, with every error that occurs the server is notified, in the server side a bug is open in BugZilla (this is what we use, you can use any other hook you want).
If I use a web-service based application then there's a web-service call for a client error.
one would say you shouldn't sample the server with every error, I disagree with this comment because an error in the client side is rare, it goes thorough QA before being released to the client so I want to know immediately on every error the client is experiencing.
In Silverlight I like to use a WebClient to log back to a web service somewhere -- you can do this directly in the Silverlight application without calling out to JavaScript.
To catch exceptions that are fired when your code isn't on the stack, you can use the Application.UnhandledException event.
I've used the same approach as Avi Tzurel - you need to know on the server side when an error appeared in the Flex client. If you want to collect more data (all the log messages, warnings) I would use an internal buffer and I will flush it asynchronously.
Anyway, you need to take into consideration if your customers are ok with this approach..maybe you need their agreement before sending the error message to the server.
I basically percolate all errors to the top, and capture them in the unhandled exception. I display a friendly message to the user. However, throughout my application I implement an ILogger interface. This interface can be initialized with various levels and handles any messaging. You can set it up so the user can add an init param to determine whether or not to transmit the errors to a service, and I typically have the logger write the messages with Debug.WriteLine if the debugger is attached to make it very easy to trace issues in debug mode.
In Silverlight you may want to consider the Logging and Exception Handling Application Blocks from the Silverlight Integration Pack for Enterprise Library.
I'm inheriting a legacy project, and there's a page that calls a method that makes a web service call. Load and performance testing has detected that this page sometimes takes a really long time to close, but usually it's fine, and if there is one hanging, all other requests for that page hang until the first one resolves, and then they all resolve.
I think this might have something to do with the web service being instantiated and not disposed, but I don't know how I can be more sure. I tried to add a delegate to the Dispose method but that doesn't seem to ever fire. (I'm not sure it would without Dispose being called explicitly, but that doesn't really matter.)
So what can I look for on the production server or any deployed environment to watch those requests pile up and go out (or get handled in an orderly manner, if they aren't the problem)?
You might consider using a tool like .NET Memory Profiler. You can use it to attach to your running application, and it can find and report all undisposed objects.
I think they have a free two week trial.
In your web app code, you could write to a log (event log, text file) right before you send a request, and again right after you get the response. Include some identifying information about the request. Add timestamps.
If you only want to use this while debugging, wrap it in #debug.
Or if you want to test in release mode, you could put a boolean in appSettings in web.config so you could turn the logging off and on.