In one of our client deployments of jboss5.1 mysql and an JSF application we get this one line error
16:46:08,970 ERROR [org.jboss.aspects.tx.TxPolicy] [] - [] (WorkManager(2)-17) javax.ejb.EJBTransactionRolledbackException
it happens every 15 seconds eaven if we dont have any chron jobs on that time scale.
We have two ears deployed on the server and if I undeploy one of them the error stops. So it must be something related to the aplication. The strange thing is that we have not touched that ear for a long time and this error started to appear withowt redeploy or any code change.
Any hints on how can I dig furthure to resolve this strange error?
go look at the following link
https://community.jboss.org/message/830295
https://community.jboss.org/message/635405?_sscc=t
Related
In using realbrowserlocusts class it appears that I'm limited in any exception handling.
The only reference that partially works is: self.client.wait.until(EC.visibility_of_element_located ....
In a failed condition where the element is not found the script simply starts over again. With the script I'm working with I need to maintain a solid session state; I need to throw and exception(report an error), log the user out and then let the script start over again. I've been testing out the behavior with the locust.py script that Nick B. created with several approaches to "try, except" and they work running without realbrowserlocusts (selenium only) but with it the execution just stops.
Any examples would be greatly appreciated.
In its current format I've been able to run 3x the amount of a browser-based load per/agent/slave than our commercial tool. My goal is to replace it with a locust/selenium approach.
locust-plugins's WebdriverUser has a little bit better exception handling I think. A failure to find an element will log a failed request and if you use RescheduleTaskOnFail (as in the the example) it will restart the task when that happens.
https://github.com/SvenskaSpel/locust-plugins/blob/master/examples/webdriver_ex.py
I tried geocoding in Modeler v18 and therefore I installed the ESRI-geocoding extension from the Hub, which was possible just after updating to v18.1.
However now, whenever I try to use any of these nodes - ReverseGeocodingESRI, GeocodingESRI, GoogleMaps, Heatmaps, I get the error I wrote in the title.
Is there anything I can do? I'm using the Student Version of this program.
Thanks.
I ran into this issue when trying to map a generated prediction from an auto-classifier node. To get around it I just reclassified into a new variable and it worked fine for me!
On a script which has been working fine for some time and unchanged, today I get
'Execution failed: Data storage error'
on a line which consists simply of:
PropertiesService.getScriptProperties().setProperty('runMode', 'LIVE');
What can I do to fix this?
Is this some kind of server error?
It's an error from Google. An issue as already been submitted, you can upvote it (click the star in the title) : https://code.google.com/p/google-apps-script-issues/issues/detail?id=6856
[EDIT] Seems to be up and running now.
Yes, the google-apps-scripts-issues 6856 describes the problem exactly, as experienced today by dozens of users. Appears to have been fixed at approx 14:00 GMT 24-Mar-17.
Would like to know whether we need to code around the possibility of a repeat of this error.
SSIS package in question runs a series of stored procedures and fills 13 different excel files with results and sends those excel files to 13 different users in attachments. Package run stops with the message in the title of this question, sometime right in the middle of sending or for example today, on the 4th user. The files get created because I can see them in their directories so only the send mail task is failing. When I go back to visual studio and execute each send task manually, send task works fine even though sometime it still gives me the error yet, still sends the right file to the right person but not thru SSIS package run in SQL server... I tried to delay SMTP processes thinking that might be in the way (to 660000 miliseconds) but did not help. Has this happened to anybody?.. Thanks for all your answers in advance.
Here is the full message for a task that sent the e-mail with attachment regardless the error when task was manually executed...
[Send Mail Task] Error: An error occurred with the following error message: "The operation has timed out.".
Progress: The SendMail task is completed. - 100 percent complete
Task Send Mail Task for Inventory Reports 038 failed
Finished, 12:03:03 PM, Elapsed time: 00:00:00.655
I think I figured it out why this was happening. In case somebody / anybody is interested, here is what I think has happened.
I was trying to expand the timeout period thru a script task, playing with Threading.Thread.Sleep value but I neglected to do the same in my SMTP connection properties. When I changed the timeout value in properties for SMTP connection, error messages stopped coming :)
I wish I could post a picture to show you where exactly that property is located but my reputation failed me!.. :( (less than 10 points yet)
I am in the process of completing all of my changes then I will post again with final result hoping that will resolve all of my problems.
Thanks to all who showed interest.
I had a non-OSGi application. To convert it to OSGi, I first bundled it up and gave it a simple BundleActivator. The activator's start() started up a thread of what used to be the main() of my app (and is now a Runnable), and remembered that thread. The activator's stop() interrupted that thread, and waited for it to end (via join()), then returned. This all seemed to be working fine.
As a next step in the OSGiification process, I am now trying to use OSGi configuration management instead of the Properties-based configuration that the application used to use. So I am adding in a ManagedService in addition to the Activator.
But it's no longer clear to me how I am supposed to start and stop my application; examples that I've seen are only serving to confuse me. Specifically, here:
http://felix.apache.org/site/apache-felix-config-admin.html
They no longer seem to do any real starting of the application in BundleActivator.start(). Instead, they just register a ManagedService to receive configuration. So I'm guessing maybe I start up the app's main thread when I receive configuration, in the ManagedService? They don't show it - the ManagedService's updated() just has vague comments saying to "apply configuration from config admin" when it is passed a non-null Dictionary.
So then I look here:
http://blog.osgi.org/2010/06/how-to-use-config-admin.html
In there, it seems like maybe they're doing what I guessed. They seem to have moved the actual app from BundleActivator to ManagedService, and are dealing with starting it when updated() receives non-null configuration, stopping it first if it's already started.
But now what about when the BundleActivator's stop() gets called?
Back on the first example page that I mentioned above, they unregister the ManagedService. On the second example page, they don't show what they do.
So I'm guessing maybe unregistering the ManagedService will cause null configuration to be sent to ManagedService.updated(), at which point I can interrupte the app thread, wait for it to end, and then return?
I suspect that I'm thoroughly incorrect, but I don't know what the "real" way to do this is. Thanks in advance for any help.
BundleActivator (BA) and ManagedService (MS) are callbacks to your bundle. BundleActivator is for the active state of your bundle. BA.start is when you bundle is being started and BA.stop is when it is being stopped. MS is called to provide your bundle a configuration, if there is one, or notify you there is no configuration.
So in BA.start, you register your MS service and return. When MS is called (on some other thread), you will either receive your configuration or be told there is no configuration and you can act accordingly (start app, etc.)
Your MS can also be called at anytime to advice of the modification or deletion of your configuration and you should act accordingly (i.e. adjust your app behavior).
When you are called at BA.stop, you need to stop your app. You can unregister the MS or let the framework do it for you as part of normal bundle stop processing.