We have a service that uses Drools quite heavily. Would like to improve the performance by running it on GraalVM.
Is it possible to run Drools on GraalVM without using Kogito?
Disclaimer: I'm one of the Drools developers
It's definitely possible, as you've already notice, we do indeed support native image compilation with our Quarkus backend, but it'll require you to write you some code, there's no such possibility in the current codebase.
Please note that only the executable model will be supported with the static component injection (the drools-core-static module in Kogito)
Is there a reason why you don't want to use Kogito though? We are really interested. Please join our community channels or the mailing list if you want to share your feedbacks, as SO is not the best platform for it.
Thanks for your support
I am building up a chart with 582 literal data points. When I call WordprocessingDocument.Close() I get an IsolatedStorageException.
This doesn't make sense to me because the OpenXML SDK, as I understand it, is totally self contained writing data to a stream. There's no calls to Office or anything else that could hit this issue.
Be that as it may, is there anything I can do to avoid this issue?
thanks - dave
I did some research into the IsolatedStorageException related to large XLSX files and found solutions to your problem.
According to Eric White's blog, when legacy OpenXml generates a file larger than 10M it needs to take advantage of Isolated Storage. If mulitple threads access the Isolated Storage during report generation System.IO.Packaging will throw the IsolatedStorageException.
This is because the System.IO.Packaging that is baked into .NET was not written well enough to handle these scenarios. That System.IO.Packaging can't be changed.
To remedy this issue, you can try one of these solutions:
Refactor your code to use a new OpenXml built on a System.IO.Packaging that Eric White refactored to remove the Isolated Storage depedency. Check this chart for reference and use the correct NuGet command to bring in the new version without the WindowsBase dependency.
Don't refactor your OpenXml code, but change your report generation user interface to prohibit (if possible) or discourage generating files larger than 10M.
If your OpenXml code is embedded inside an IIS based web solution and refactoring your code is not feasible, try one of the solutions provided by this blog. These techniques aim to provide permissions needed by IIS to try and get around this exception and might not be related to Eric White's concern.
Without more information about your solution architecture, these are the solutions I can recommend at this time. Hope they help.
I am working in a Python script for updating CI in a uCMDB.
By the moment I have a full script with Python 2.7 and Suds(also cx_Oracle for access to db).
Been searching about Soap clients but don´t know which to use, I´ve seen: suds, zsi, rinse, pysimplesope, SOAPpy. Some abandoned, other with too Little docuementation.
Which do you recommend and why?, preferably available for Python 3.5.
Give http://docs.python-zeep.org/en/latest/ a try. I'm the author and it's fairly new but it is imho one of the better options available now. I'm also trying to get as much feedback as possible since soap has a lot of edge cases.
suds-jurko is a friendly fork of suds that supports Python 3.
I wish to use the application known as Processing to create interactive graphs and figures to use in a presentation for the Arizona JSHS competition. I have used the widely popular LiveWeb application to be able to embed java into the power-point. But when I do the same thing with Java applications made with Processing it gives an error.
"Error: Unexpected identifier or string. http://localhost/applet/index.html"
I have tested it with locally hosted Java applets and Processing applets, both work run normally. But only the Java applet (which is very similar to the processing applet) works in LiveWeb.
Does anyone have suggestions to get around this? Do you think I could import processing library's into Eclipse and work from there?
One potential solution would be processing.js. It is a javascript version of processing that may fit your needs.
The only place where I found informations on G-WAN web server was the project web site and it looked very much like advertisement.
What I would really know is, for someone who is proficient with C, if it is as easy to use and extend that other architectures. For now I would mostly focus on scripting abilities.
Are C scripts on GWAN easy to write ?
Can you easily update and upload new C scripts to the server (say as easily than some PHP or Java pages on other architectures) ? Do you have to restart the server when doing so ?
Can you easily extend it with third party or existing C libraries ?
Any other feedback welcome.
Well, now G-WAN is available under Linux, I am using it for more than 6 months.
The C scripts are fully-ANSI C compatible so there is no difference for any seasonned C programmer.
To update them on the server, you can edit them directly in the /csp folder (remotely via SSH) or locally on a test machine (and copy them later): G-WAN reloads scripts on-the-fly when they have been changed on disk (no server stop required).
G-WAN C scripts can use any existing library (starting with all those under /usr/lib) without any configuration or interface: you just have to write a '#pragma link' followed by the name of the library at the top of your script.
What I found really useful is the ability to edit C scripts and refresh the view in the Internet browser to see how my code works.
If there is a compilation error, then G-WAN outputs the line in the source code (just like any C compiler).
But where it enters the extraordinary area, is when you have a C script crash: here also it gives you THE LINE NUMBER IN THE SOURCE CODE (with the faulty call and the backtrace).
Kind of black-magic when you are used to Apache modules.
My experience with G-WAN and its C scripts are:
The G-WAN community is very small. Questions you have are mostly answered by its single developer.
I consider the API not mature: it's not as "clean" as Java APIs.
The limitation, but at the same time the power, of C: it's a systems programming language. So writing application logic in it must be done carefully.
You generally need to be a good developer to get good results: if you do something wrong, the server crashes fast and hard (Unix-style).
I've written some scripts now, to try out G-WAN. Overall, it's been very "productive": not much bugs and it works if you follow the guidelines and don't want to do too much funky stuff you expect it to have, like mature web servers. However, I have got the feeling I'm reinventing the wheel a lot of times.
G-WAN also support scripts written in other programming languages (C++, Objective-C, Java, etc.) so you will benefit from whatever native libraries each language implements.
For C scripts, well, the /usr/lib directory lists more than 1,500 libraries that G-WAN can re-use with a simple #pragma link "library".
I found it neat to be able to write a Web application with a part in C, another in C++ and a third one in Java!
Benchmark shown how G-wan fare poorly at handling these tests.
http://joshitech.blogspot.sg/2012/04/performance-nginx-netty-cppcms.html
I have been using G-Wan for about two years. I consider it highly stable and production ready for static files. I have a number of static sites running for over a year with no issues.
I have built some small scale dynamic sites in C with it as demos/test projects. A bittorrent tracker and a real time analytics platform both using the KV Store for data backing.
In my view building large scale dynamic sites in G-Wan is possible but only with a significant investment in development and support. G-Wan is better suited to building robust highly scalable "enterprise grade" applications than tossing something together over a weekend.
I use G-Wan for a CMS http://solicms.com but for now, I use Ruby as primary language.
I have used G-wan for some preliminary testing and it does benchmark well. I have found a few points of concern that make it so that I will not likely use it for any of my projects. I have found that it seems to cache responses for about 0.5secs to speedup the responses/second and I can't have only some of the responses hitting the application code. Also the key/value store is great for cache and temporary data storage but I'm not sure how well it will work as a real back-end storage method.