I'm using Seam and getting a "Concurrent call to conversation" error. What does this mean?
I have a button that takes 5 min to process. I get this error within 2 minutes. Setting the concurrent-request-timeout to 10 min does not seem to work. Is there a way to block all other requests until the first one has completed?
Section 6.9 of the Seam documentation explains strategies for handling concurrent calls in a conversational context.
don't think it's great idea to block all other request for SUCH long operation, much better approach is to have it to run asynchronously.
You can take a look here http://achorniy.wordpress.com/2009/07/14/avoid-concurrent-call-to-conversation/ but this is the solution to allow you to block other requests during the short period of time (of course it can block them for a long time but that's not good approach in general to make user to wait for such requests)
You can take a look here for a good example of how UI can be organized to work with async on backend (see richfaces livedemo "Ajax Support" Push/Pull examples)
Here is the solution - use richfaces progressBar, call the seam asynchronous method to run long-process and pass the ProgressBean with parameters to async-method(it should be accessible from yuor conversation bean which you use in JSF) and periodically update progress-status in long-running task
This approach is explained in details here [Show dynamic process progress in Seam/Richfaces][1]
[1] http://achorniy.wordpress.com/2010/10/22/show-dynamic-process-progress-in-seam-richfaces/
Related
I was wondering if it is possible to use Julia to perform computations on a webpage in an automated way.
For example suppose we have a 3x3 html form in which we input some numbers. These form a square matrix A, and we can find its eigenvalues in Julia pretty straightforward. I would like to use Julia to make the computation and then return the results.
In my understanding (which is limited in this direction) I guess the process should be something like:
collect the data entered in the form
send the data to a machine which has Julia installed
run the Julia code with the given data and store the result
send the result back to the webpage and show it.
Do you think something like this is possible? (I've seen some stuff using HttpServer which allows computation with the browser, but I'm not sure this is the right thing to use) If yes, which are the things which I need to look into? Do you have any examples of such implementations of web calculations?
If you are using or can use Node.js, you can use node-julia. It has some limitations, but should work fine for this.
Coincidentally, I was already mostly done with putting together an example that does this. A rough mockup is available here, which uses express to serve the pages and plotly to display results (among other node modules).
Another option would be to write the server itself in Julia using Mux.jl and skip server-side javascript entirely.
Yes, it can be done with HttpServer.jl
It's pretty simple - you make a small script that starts your HttpServer, which now listens to the designated port. Part of configuring the web server is that you define some handlers (functions) that are invoked when certain events take place in your app's life cycle (new request, error, etc).
Here's a very simple official example:
https://github.com/JuliaWeb/HttpServer.jl/blob/master/examples/fibonacci.jl
However, things can get complex fast:
you already need to perform 2 actions:
a. render your HTML page where you take the user input (by default)
b. render the response page as a consequence of receiving a POST request
you'll need to extract the data payload coming through the form. Data sent via GET is easy to reach, data sent via POST not so much.
if you expose this to users you need to setup some failsafe measures to respawn your server script - otherwise it might just crash and exit.
if you open your script to the world you must make sure that it's not vulnerable to attacks - you don't want to empower a hacker to execute random Julia code on your server or access your DB.
So for basic usage on a small case, yes, HttpServer.jl should be enough.
If however you expect a bigger project, you can give Genie a try (https://github.com/essenciary/Genie.jl). It's still work in progress but it handles most of the low level work allowing developers to focus on the specific app logic, rather than on the transport layer (Genie's author here, btw).
If you get stuck there's GitHub issues and a Gitter channel.
Try Escher.jl.
This enables you to build up the web page in Julia.
I want to provide my own implementation of TimerExtention in place of DurableTimerExtention provided by Delay activity, so that I can test workflows that use delays.
How can I accomplish that?
I have WorkflowService instance and its root Activity. The workflow service is hosted in WorkflowServiceHost, (though I can not figure out how to get WorkflowInstance instance)
One way to test your workflows is to use the Microsoft.Activities.UnitTesting on CodePlex. It has the capability to mock activities using XAML Injection. See here for more details.
In the case of a Delay activity you can do things a lot simpler though. Instead of hard coding the Duration to a fixed value I normally create a config object with the duration in there. In the Delay activity I just enter an expression like Settings.WaitForPaymentDuration. In production the Settings.WaitForPaymentDuration will be set to something like 30 days but in a test I can set it to 1 second instead without changing the workflow at all.
I have had a similar interest in mocking the TimerExtension, I wrote a blog post about it. In that post I inject my own implementation of the TimerExtension using WorkflowApplication.Extensions.Add<T>(Func<T>). WorkflowServiceHost also has this collection. You could replace the concrete class I have in my example with a mock. I wrote it targeting 4.5, but it should work with anything that uses the Extension collection. Its in 4, not sure earlier versions.
[Link]
I am currently trying to use the "Invocation tags" of Mate to call my web services and delegate the WS-responses to my fault/result handlers.
I want to use the generated proxies, provided by the Flex Builder, and not the plain <WebService> or <WebServiceInvoker> tags.
I actually failed using several techniques:
<WebServiceInvoker> does not work with the generated proxies.
<AsyncMethodInvoker> needs some complicated successType that I could not get to work with the WS-calls. And defining the events seems redundant to me. I want it simple and easy to read, the code will be touched by other people than me!
<MethodInvoker> can't use instances, and it also can't handle the proxies' AsyncToken
<DelegateInvoker> Looked fine at first. It calls the service but doesn't fire valid result events (infinite busy cursor). Even though i can successfully bind to the XYZ_lastResult of the WS-proxies, and a WS-call results in getting valid data from the WS-backend, the <faultHandlers> and <resulthandlers> are not executed. There is some solution for the DelegateInvoker that changes code in the generated proxies, which i definately do not want to do!
So here is my question: Is there a simple(!) way of using default Flexbuilder generated proxies with the Mate Invocation tags?
It appears that your request is not that uncommon to Mate. Check out this couple of threads in their forum:
http://mate.asfusion.com/forums/topic.php?id=424
http://mate.asfusion.com/forums/topic.php?id=421
The solution is to modify some bits of the auto-generated code... which in a way ruins the whole point of using code generation.
I have a flex application that repeatedly polls a remote XML file to detect changes, but I've found that once the file hits a certain size, the poll blocks the UI and makes the page unresponsive for a short time.
Is there any way to ensure that the call made to the server or the event from the flash.utils.Timer class runs asynchronously to the main UI thread?
It sounds like the blocking is caused by Flash parsing the XML rather than the actual loading.
If that is the case then you can keep loading the file and just check the size of the raw data you get back - if it's bigger, parse it and take the parsing hit. Otherwise toss the data and wait for the next request.
There's no explicit way to do threading with Flash at this time. Certain tasks happen async naturally (network and pixelbender comes to mind) but that's it.
Branden's right -- the code we write essentially always happens on the main thread; while the network call itself does happen on a background thread, the handling of that call happens on the main one.
One thing to keep in mind is that the WebService and HTTPService classes will likely attempt to serialize your responses automatically, which could mean taking that processing hit unnecesarily. Using URLLoader, on the other hand, could give you more direct access to the response data, allowing you to work more directly with it without the unnecessary overhead of that built-in processing.
In that light, if you find you do have to process the entire XML file, you might consider breaking it up into chunks somehow, and distributing the processing of those chunks into separate functions, rather than handling everything within the scope of a single function. Just doing that might allow the player to continue updating the UI while you're processing that big bunch of text (processing a bit, exiting the function, rendering the UI, entering the next function, rendering, and so on); Oliver Goldman, an engineer on the AIR team, did a presentation on this concept at last year's MAX conference.
Hope it helps!
Like mentioned, AS3 is single threaded. But there are a couple of ways to handle your situation. Here are ur possible choices:
First,make sure you really need to parse entire XML when loaded and cant just keep the loaded xml nodes in memory as the data model (XML being a native data type now). Sometimes I create value objects by passing them an XMLNode and thats kept in memory till a node value is needed at which point I read it. This allows you to keep some of the parsing for later.
If you are using an ArrayCollection or similar structure to hold data, try using a primitive Array ( see http://www.arpitonline.com/blog/?p=114 for an issue I ran into)
See if you can creatively use callLater()(http://livedocs.adobe.com/flex/2/langref/mx/core/UIComponent.html#callLater())
Can you pass the data to the client in a native format like SWX or using Remoting
Can you use data paging? ArrayCollections and I am pretty sure XMLCollection support it
Side Note:
While AS3 is single threaded, Pixel Bender and I think Alchemy (http://labs.adobe.com/technologies/alchemy/) run on a different thread. There have been a couple of experiments on blogs using Pixel Bender to do calculations which dont slow the UI of the app (Example:http://elromdesign.com/blog/2009/02/09/using-pixel-bender-to-do-heavy-lifting-calculations-makes-flash-player-multi-thread/).
Also please vote on this feature enhancement ticket with Adobe if you feel the need for this feature enough:
https://bugs.adobe.com/jira/browse/ASC-3222
I'm building a Web Page that allows the user to pick a color and size. Once they have these selected I need to perform a lookup to see if inventory exists or not and update some UI elements based on this.
I was thinking that putting all the single product data into multidimensional JavaScript array (there is only 10-50 records for any page instance) and writing some client side routines around that, would be the way to go for two reasons. One because it keeps the UI fast and two it minimizes callbacks to the server. What i'm worried about with this solution is code smell.
As an alternative i'm thinking about using a more AJAX purist approach of using HTTP handlers and JSON, or perhaps a hybrid with a bit of both. My question is what are your thoughts as to the best solution to this problem using the ASP.Net 2.0 stack?
[Edit]
I also should mention that this page will be running in a SharePoint environment.
Assuming the data is static, I would vote option #1. Storing and retrieving data elements in a JavaScript array is relatively foolproof and entirely within your control. Calling back to the server introduces a lot of possible failure points. Besides, I think keeping the data in-memory within the page will require less code overall and be more readable to anyone with a more than rudimentary understanding of JavaScript.
i'm against Ajax for such tasks, and vote (and implemented) the first option.
As far as I understand, you won't create Code smells if the JS part is being written by your server-side.
From a user point-of-view, Ajax is an experience-killer for wireless browsing, since any little glitch or mis-service will fail or simply lengthen the interaction by factors of 20(!).
I've implemented even more records than yours in my site, and the users love it. Since some of my users use internet-caffee, or dubious hotel wifi, it wouldn't work otherwise.
Besides, Ajax makes your server-vs-client interaction code much more complex, IMO, which is the trickiest part in web programming.
I would go with your second option by far. As long as the AJAX call isn't performing a long running process for this case, it should be pretty fast.
The application I work on does lots with AJAX and HttpHandler, and our calls execute fast. Just ensure you are minimizing the size of your JSON returned in the response.
Go with your second option. If there are that few items involved, the AJAX call should perform fairly well. You'll keep your code off the client side, hopefully prevent any browser based issues that the client side scripting might have caused, and have a cleaner application.
EDIT
Also consider that client side script can be modified by the user. If there's no other validation occuring to the user's selection, this could allow them to configure a product that is out of stock.