blue dot of death!

Classic Servoy
1

I have a situation that seems to have popped up only in the last day or two.

I have a total of 35 user licenses and I am only using about 20 at any one given time.
A user will log in and the blue dot at the bottom will come on like someone is editing the record they are on. The light will stay on making it very difficult for the user to click on any of the menu buttons to go to other layouts in the solution. I know for a fact that the current record the user is on is not being modified, because it is the user info table the runs the main page layout, and the record will be unique to each user.
Then, suddenly for no reason at all, the blue dot will go out and the user will be able to navigate to other layouts with relative ease.
When I watch the user idle status during one of these episodes, it shows that the user in question will be trying to hit the server every second instead of every couple of seconds or even minutes like a normal user would.

This episode can flare up between 1 to as many as 3 users at a time. I don’t see any rhyme nor reason for the episode.

Has this happened to anyone else?

2

Sounds like a ‘databroadcasting to death’ situation. The blue dot indicates a databroadcast is going on and I suspect many users are looking at the same tableview and you are changing a lot life (eg stored calcs on date) in that tableview?

3

I have no stored cals on the affected layout at all. In fact I have only 4 calcs in the enitre layout.

I have removed any methods that were not absolutely necessary and confirmed that nothing is running via onShow, onLoad or onSelection that would cause any data broadcasting problems.
I am now going to restart the machine to see if a machine reboot will solve the problem.

I will report back any findings.

4

So I have restarted the machine, and the more users jump on the system, the more the blue dot appears. At first is was only on my main menu layout. After a while, the blue dot is on no matter what layout the user is in. It appears that under certain conditions, two users cannot be in the same layout at the same time. Even if they are on different records in the same layout.

What I don’t understand is that there is no calculating or changing of data going on every second. I understand the data broadcasting when a record is open and being changed, but I don’t have more than one user on any particular record at a given time. In the case of the main menu, since the record the user is on is there own unique login and user info record, it is not possible for several users to be “editing” the same user login info.

As far a calculations are concerned, this behavior just started in the past 3 days. I am at a loss for what is being done differently in the past 3 days. In a effort to see if it what something I will roll back to a previous release to see if that makes a difference.

5

Jim,

We had this same situation.

3.5.1 solved the databroadcast problems were were having.

We would have up to 1000 update queries a minute firing.

It was always between two users, but random as to which two users. All 20 clients could be on the same page, but whichever two had the problem, were the only ones firing updates and databroadcasts. I could always identify them by going to the servoy admin URL and watching a pair of clients trade places at the top of the client list every time I refreshed - or monitoring the servoy_log table to see which userid’s were “stuck” in blue light special mode :slight_smile:

It seemed to be related to fields set in the DB with a set number of decimal places. One client would set the field to 25.005 (25.00 in the DB), the next client would get the broadcast of such, and say…no, its 25.005 and set it again (the DB still stores 25.00). The original client would then see the 25.00 from the databroadcast refresh and again try to reset it to 25.005.

It seemed to be a floating number problem where the decimal places weren’t respected by Servoy.

But, again, 3.5.1 solved our problem with no changes to the layout, fields, db or calcs.

NCM
FSCI

6

The problem is that in 3.5.1, there are other issues that currently make my solution unusable.

Did you have this issue on Servoy 3.1.7?
Perhaps if I went back to 3.1.6 I might be OK.

7

Can you upload the solution to our support system? We can have our engineers look into it then ASAP.

8

I assume you would want sample data too?

9

A solution in which the problem can be reproduced. In general this requires data, yes.

10

I have made an entry on the support system. Please let me know what you find. Thanks.

11

We had this problem on 2.2.7 - 3.1.6 and even in 3.1.7 (although wasn’t as severe for some reason)

What issues in 3.5? We had a few, but eliminated all but a printing bug that servoy said is fixed in 3.5.3.

NCM

12

I think I may have found the problem.

The layout that was giving me all of the problems had a portal to another layout that provided concurrent user information for me. It was a portal that was only visible to me and not to the general users. In that layout there were stored date calculations. I removed the column that stored the data and restarted the server.
So far, that seems to have done the trick. The server is once again working normally.
I am continuing the monitor the traffic to see if the problem returns.

13

What were the issues that keep you back from moving to 3.5 - Servoy issues or solution related issues?

14

What were the issues that keep you back from moving to 3.5 - Servoy issues or solution related issues?

First, I have a couple of layouts that for some reason will not pop up when clicked in at the main menu layout.
They are Timesheet (Timesheet_approval) and Etime sheet (time_etime).
When you click the button to take you to the layout, it freezes. I have not yet been able to determine why this happens since it does not occur in 3.1.7. I have to click the forward and back button several times for the layout to load correctly.

Secondly, when I am in the timesheet_approval layout and I do a find, I get the following error: “Search Failed … try show all. java.lang.IllegalArgumenException: Validation failed for ‘department’, with value:”

I reported the Second problem to the support system, but I haven’t heard back except to say, are you sure you are in find mode. And yes, clearly I am in find mode!

So because I can’t seem to get around those two issues, I have held off on moving to Servoy 3.5.x.

15

The upgrade problems are now sorted out. :wink:

16

It’s back!

The mass data broadcasting problem seems to have returned.
I have upgraded to 3.5.3 and the problem persists.

Here is the issue.

I have a int(11) column that holds the creation date of the record in Unix Time Stamp. Since this info is helpful to the computer but not to humans, I have created a stored calculation in a date() column. The calculation is the data equivalent of the UTS creation date.
When there is two or more users on the same record, it starts to lock each other up. When I look at the client section on the web page, it shows the two or more users that are being affected leapfrogging over each other constantly until one person moves off the record. This becomes difficult to do if the record keeps locking and unlocking.

I need a way for users to see and be able to search based on the creation date of the record.

How can I get around this problem?

17

I blanked out my performance log and just watched what was happening. Here is the chatter:

00:00:247	208	00:00:001	Refresh/Rollback	select job_id, user_id, group_id, modified_by, modified_time, created_by, created_time, status, job_name, ticket, producer, job_status, client_1_id, client_1_role, client_2_id, client_2_role, client_3_id, client_3_role, scan_film_stock, scan_aperture, scan_resolution, scan_format_name, scan_color_correction, scan_bit_depth, scan_gamma, scan_tar_style, scan_file_format, scan_media_stock, scan_client_provided_media, scan_conversion, scan_handle_head, scan_handle_tail, scan_notes, rec_description, rec_incoming_media, rec_aperture, rec_incoming_resolution, rec_incoming_file_format, rec_incoming_bit_depth, rec_incoming_gamma, rec_outgoing_resolution, rec_outgoing_file_format, rec_outgoing_bit_depth, rec_outgoing_gamma, rec_color_correction, rec_conversion, rec_notes, lab_lab, lab_prints, lab_lights, lab_lights_red, lab_lights_green, lab_lights_blue, color, ticket_type, purchase_order, date_needed, subject, bw_color, ticket_instruction, aspect_ratio, studio, supervisor, type_of_record, output_to, neg_to, print_to, lights_other, daylite, cr_special_instructions, handles, uf_name, production_number, memo, negative_instruction, lab_po, ast_editor_id, editor_id, neg_cutter_id, post_auth_id, fmp_recordid, fmp_ticket_date, ordered_by, fmp_film_format, current_status, fmp_remarks, fmp_update_date, fmp_update_time, fmp_creation_user, fmp_update_user, bill_date, fmp_creation_date, fmp_creation_time, fmp_creation_username, fmp_effects_concatenated, fmp_salesperson, fmp_archive, fmp_ticket_serial_pull_neg, fmp_effects_concatenated_2, fmp_billed_date, fmp_effects_for_print, fmp_modid, fmp_serial_number_internal, fmp_neg_cutter, fmp_editor, fmp_ast_editor, fmp_post_auth, fmp_production_number, fmp_lab_lab, fmp_memo, fmp_ticket, fmp_studio, fmp_date_needed, fmp_subject, fmp_purchase_order, fmp_ordered_by, fmp_aspect_ratio, fmp_bw_color, fmp_current_status, fmp_bill_date, fmp_job_name, fmp_ticket_type, fmp_ticket_instruction, fmp_lab_po, fmp_scan_resolution, fmp_type_of_record, fmp_lab_prints, fmp_rec_outgoing_resolution, fmp_output_to, fmp_neg_to, fmp_lab_lights, fmp_lights_other, fmp_print_to, fmp_daylite, fmp_rec_incoming_media, fmp_rec_aperture, fmp_cr_special_instructions, fmp_rec_notes, fmp_negative_instruction, aka_name, sales_id, supervisor_id, lab_printer, shot_color_info, hours_difference_total, vendor, lineup_notes, coordinator_notes, art_coord_note, do_coord_note, di_coord_note, hours_discount, ycm_ref_lab, ycm_ref_film_stock, ycm_exhibition_format, ycm_direct_di_test, ycm_contast_test, ycm_contast_test_notes, ycm_data_received, ycm_data_received_note, ycm_ref_print, ycm_ref_print_note, ycm_sound_track, ycm_sound_track_note, ycm_timing_lights, ycm_timing_lights_note, ycm_data_received_bydate, ycm_ref_print_bydate, ycm_sound_track_bydate, ycm_timing_lights_bydate, ycm_dvd, ycm_dvd_bydate, ycm_dvd_note, ycm_sep_type, ycm_production_order, po_date, release_date, number_of_reels, film_length, di_house, hours_bid_total, hours_used_total, salesperson_show, ticket_voided, accounting_note, p_o_amount, percent_of_complete, amount_remaining, lab_billing, da_frame_format_id, da_fps, da_capture_path, da_final_path, da_shot_path, show_job_id, billing_time, show_job_alias_id, created from job_job where job_id = ? limit ?
00:00:077	104	00:00:000	Update	update job_job set created=? where job_id = ?

The stored calculation is ‘created’. It looks to do an update and then a rollback.

This only occurs when two users are on the same record.

18

So I removed my calculation and the users seem to be running fine now. My question is, why does Servoy have such a big problem with stored calculations in a date column from an int column?

Earlier posts about this problem said that it was solved in 3.5.x.

Obviously the problem was not fixed.