Anders Melander

Okay then. I doubt you will have any luck with getting this resolved unless you can provide additional details - which will require an effort on your part.

Also, Embarcadero doesn't run this forum and probably doesn't follow what goes on here. If you want them to take notice of the problem you will have to report it to them (which isn't possible at the moment).

I haven't analyzed the problem at all, and I have no solution for you, but a few things struck me when I read the description of your problems.

21 hours ago, mitch.terpak said:

The issue in threading.pas seems to stem from this property being explicitly set to true in TThreadPool.Create:

[...]

despite already having a default value or having been set to False:

property UnlimitedWorkerThreadsWhenBlocked: Boolean read FUnlimitedWorkerThreadsWhenBlocked
      write FUnlimitedWorkerThreadsWhenBlocked default True;

 

1. The default property directive only has meaning for published properties and is only used by the VCL streaming mechanism to determine if a property needs to be written to the DFM or not. It has no practical purpose here. I can only think they included it so it's easier to see what the default value is when looking at the source.
2. It doesn't already have a default value. The default value is the one being set in the constructor, hence: True.
3. It isn't set to False. If you are setting to False, then it must be after the constructor has executed.

21 hours ago, mitch.terpak said:

This leads to the TThreadPool.TThreadPoolMonitor.GrowThreadPoolIfStarved procedure unnecessarily increasing the number of worker threads.

You do you believe that the worker threads being increased is unnecessary?

I don't know but I would guess that growing the pool beyond the limit is done to try to avoid the deadlock that could occur in some scenarios if the limit it was a hard limit (e.g. all threads blocked waiting for something that can only be produced by another thread which can't be created because the limit has been reached).

21 hours ago, mitch.terpak said:

The access violation in 12.0 (using a custom thread pool) often occurs here:

Exactly where? If it's an access violation then there must be an invalid pointer. I can see 3 different candidates in that line of code: Self, FThreadPool and FThreadPool.FMonitorThreadWakeEvent.

You should be able to determine which one it is with the debugger.

Okay. Can't help you, sorry.

1 minute ago, limelect said:

So it is Windows 7 ported to ANY Delphi.

Any idea how to check this?

Are you asking if any version of Delphi supports Windows 7?

As designed. Look at the source of TStringHelper.ToUpper in SysUtils.

Try using ToUpperInvariant instead.

Another thing to try:

• Use SysInternal's Process Explorer to inspect the call stack the threads in the process while it's running in the debugger. Might give you a clue about what it's doing.
• Run Delphi in a debugger (you can use another instance of Delphi to do that). Then run your application in the other Delphi and break so you can examine the call stack.

Just now, PiedSoftware said:

I don't think we have that package in the app at all. We certainly haven't coded that way.

Okay but it's installed in the IDE by default and it affects the design-time performance of forms and datamodules.

Give a try; It's one of the first things I do when I install Delphi.

1 hour ago, Dalija Prasnikar said:

And this issue is fixed, but at the moment hotfix cannot be delivered due to outage.

"the check is in the mail" 🙂

1 hour ago, Dalija Prasnikar said:

You mean the issue with division with $FFFFFFFF constant? That is nowhere near being a showstopper bug.

It is for us. Some of our projects are huge, with lots of integer math optimizations involving bit shifts and funky multiplications and divisions and we simply cannot risk it when the compiler has known bugs in that area. So basically Delphi 12 has been DOA for us.

7 hours ago, Vincent Parrett said:

By pure chance this video came up on youtube this morning which articulates the point I made above ^

I'm sure the scenarios he outlined as a reason for moving to the cloud (basically cost of hardware) and then moving off it again is true for a lot of cases. It doesn't however resonate with any of the scenarios I've been or am involved with; We've moved systems to the cloud not because of hardware cost (which I can't remember having ever been an issue) but because of the cost of managing on-premise servers, providing the required infrastructure (storage, network, recoverability, know-how, etc) and securing global availability.

I think the size of a company is a big factor in whether cloud makes sense or not. If you're already paying for the "overhead" of having dedicated, competent IT staff service your on-premise clients, then it might not make sense to outsource stuff to the cloud. Of course the nature of the services being outsourced also has to be taken into consideration, but I can't see hardware cost being a factor.

Try disabling the livebinding design time packages (unless of course you're using livebindings).

2 minutes ago, limelect said:

Could you plz elaborate I do not recognize this

https://bitbucket.org/anders_melander/drag-and-drop-component-suite/src/master/

or

https://github.com/landrix/The-Drag-and-Drop-Component-Suite-for-Delphi

8 hours ago, limelect said:

as for the analyzer I cannot drop either in ide or exe

What events does the analyzer show?

8 hours ago, limelect said:

One more option is that a component I install does the problem

Hmm. The D&D suite disables the Delphi IDE as a drop target during debugging to avoid the deadlock that would occur if the application being debugged was the drop source and the IDE the drop target.

You can try to uninstall the D&D suite design time package to see if that is the cause.

The Drag and Drop Component Suite contains a demo application that can be used to diagnose a drop target (there's one for drop sources too, fwiw). You could use that to determine the exact interaction between the drop source and target. There is also a demo of WM_DROPFILES, including the handling of ChangeWindowMessageFilter*.

The screenshot below shows the Drop Target Analyzer dropping CF_HDROP data (i.e. a file) onto the WM_DROPFILES demo, which is running elevated.

2 minutes ago, Vincent Parrett said:

Contructive critique is fine, sarcastic comments like "fixed it for you" is not at all helpful and frankly annoying.   

Point taken. I apologize.

Although I have great interest in you project I haven't gotten involved at all because I simply don't have spare time or room in my head for yet another project.
Anyway, it's not my area of expertise but I would have thought that existing solutions to distributed chain-of-trust could be used. I don't really have time to think that through to an actual solution though, so I can't claim that what I ask (no SPOF) is doable at all.

Just now, Vincent Parrett said:

what are you doing (apart from picking holes) 🤷‍♂️ 

Providing critique. Are you opposed to that?

2 minutes ago, Vincent Parrett said:

The plan is eventually to move it to a cloud service which could provide the redundancy needed - gotta start somewhere.  

Okay then. I know this was originally designed as something else but IMO, if this is to be the package manager, in the sense discussed here, it would be smart to base it on a distributed architecture with no SPOF.

13 hours ago, Vincent Parrett said:

The website is a single point of failure an asp.net 8.0 application (because I have a lot of experience with it) with a react front end, using a postgresql db - running on ubuntu server on a vm on one of my servers in Sydney

Fixed it for you...

Am I wrong?

1 hour ago, Vincent Parrett said:

I understand why making it short is attractive.

Laziness.

1 hour ago, Dalija Prasnikar said:

Their internal JIRA will be migrated fully. So there will be no loss of issues in internal system. As far as the public one is concerned, I don't know whether it will be migrated or not and what are the possible issues. Evidently, it will not be migrated right away.

I guess from their perspective the internal ones are the most important, and I guess, rationally, from the customer perspective too.

Unless they are going to replicate the existing system of having two different Jira projects (one for the internal issues and one for the publicly visible ones), which I definitely would not recommend (that's how Atlassian does it and it obviously sucks for everybody), I can see how it will be a problem getting everything migrated into one project. I do not envy them this task.

However, the optics of dumping years of public issues will be catastrophic to their already strained relationship with the community. I really hope that they get this sorted out somehow.

8 hours ago, Dalija Prasnikar said:

Atlassian no longer supports JIRA on premises which Embarcadero uses.

Atlassian hasn't supported the version of Jira that Embarcadero uses since 2017...

https://www.atlassian.com/blog/2017/03/end-of-support-for-jira-6-4

8 hours ago, Dalija Prasnikar said:

https://blogs.embarcadero.com/embarcadero-quality-portal-migration/

Quote

For the time being, the existing Quality Portal system will remain accessible read only. The data on the old system will remain visible, even after the new portal will be in place.

As I interpret that, they will not be migrating data from the old to the new system.

37 minutes ago, Vincent Parrett said:

3) TStr is not a great name for this, perhaps TFormatStr or TStringFormat or something like that would be more descriptive.

And maybe get rid of the leading T since it isn't really used as a type.

2 hours ago, Darian Miller said:

I mean, people make fun of JIRA all the time but it does have some pretty powerful features.  I think JIRA sucks and JSM sucks what JIRA wouldn't.

I actually like Jira a lot. There are some things that could be better (wasted screen space, responsiveness, lack of basic features that can only be resolved with 3rd party plugins) but I don't think there's anything else that comes close to it as an issue tracker. Atlassian, however, can go to hell. I've been using their products for 20 years and I've lost count of the number of times I've sworn never to touch any of their products again. So a love/hate relationship basically.

57 minutes ago, Dalija Prasnikar said:

AFAIK, there is an option to set visibility of all issues to be automatically visible to all customers, but that option is not a default one. So I don't think visibility should be a problem here.

If that is the case, and JSM has improved substantially since I last looked at it (and from what I can see in their marketing material, it has), I think this might end up being an okay solution.

With regard to loss of existing data, as far as I can tell, the Jira Cloud Migration Assistant (the software that migrates data from server to cloud) only support Jira Server 7.6 or later. Embarcadero's Jira Server is version 6.4, released in 2015 - and it's probably been customized...

There are ways to solve that but it's a painful and fragile process involving incrementally upgrading the server to reach a supported version: 6.4 -> 7.0 -> 7.6 -> Cloud

1 hour ago, Uwe Raabe said:

a cloud based Jira (you won't get any other)

That's not quite true. Jira Server is EOL in february this year but there's still Jira Data Center which is also on-prem (and extremely expensive).

1 hour ago, Uwe Raabe said:

limited public access to the new one.

So the question is what "limited" means.

Jira is licensed per-user and I'm guessing that they're not going to buy a license for each of their Delphi users.

Instead they might be going with Jira Cloud internally and Jira Service Management (JSM, formerly Service Desk) externally. JSM is licensed per agent (internal user) with unlimited externals users (called "external customer" in JSM). I trialed JSM many years ago for external support but back then it was still licensed per external user and didn't really work that well, compared to something like ZenDesk.

As far as I know JSM does not allow one external user to see the issues raised by other external users. I.e. it's a support system; There's no interaction between external users.

So if JSM is the solution they are going for I don't see it as an improvement.

1 hour ago, Uwe Raabe said:

So the statement that the current system seems to work fine probably didn't take into account the whole picture.

As I customer I don't really care about what goes on behind the curtain. From my POW it seemed to work fine but I guess you point was that it only seemed that way.

I wish I could have your admirable optimism.

1 hour ago, Uwe Raabe said:

it is definitely a good thing and long awaited change.

Why is it definitely a good thing? The current system seems to work fine.

I can understand why they would want to migrate away from their old, unsupported Jira server but without knowing what they are going to replace it with it's hard to say if it will be an improvement.

11 minutes ago, tgbs said:

Since it will be read-only, they should transfer all unresolved issues to the new system so that they can be commented on

Don't count on it. The last time they switched system all the existing data were left behind and lost.

2 hours ago, David Heffernan said:

It's ironic that the download spikes caused by all the Delphi 12 downloads have caused this

Yeah. I could maybe forgive them their general incompetence as it's probably caused by a lack of resources - but that lie is just insulting.