Skip to main content

DNS resolving for two universals on the same server | Thinkwise Community (thinkwisesoftware.com)

As a follow-up to the final solution coming from the topic above (a dedicated indicium for every website), we stumble upon some problems with the DevExpress plugin that seem to have arosen from the new way of deploying Universal-Indicium on AWS Elastic Beanstalk. We tried with a former Indicium version and also there this problem suddenly occurred...

The following error is logged in the Indicium log when a report must be created with DevExpress:

2023-03-03T07:38:15.7065798+00:00 800001b4-0000-9700-b63f-84710c7967bb [err] An unhandled exception occurred while processing the request. (ffba027a)
Prockees.Bootstrapper.ExecutionException: DevExpress.XtraReports.DataRetrievalException: Error when trying to populate the datasource. The following exception was thrown: 
Failed to connect to the database. To learn more, see the exception details. 

Exception details:
 Connection name: <Note by author: cannot set real name here because of reserved keyword>
 Error message:
The given key was not present in the dictionary.
 ---> DevExpress.DataAccess.Sql.DatabaseConnectionException: Failed to connect to the database. To learn more, see the exception details. 

Exception details:
 Connection name: <Note by author: cannot set real name here because of reserved keyword>
 Error message:
The given key was not present in the dictionary.
 ---> System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
   at System.ThrowHelper.ThrowKeyNotFoundException()
   at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
   at .....

I tried to find a fix for this error on the internet, but all I found are fixes on the C# coding side...

Can you please help us out? 

Hi Richard, can you include the full exception stacktrace?

Hi @Anne Buit 

For the full stack trace see the attached Indicium log

@Anne Buit I just tested in our 'old’ setup with only one website deployed (via the normal way as we always did), and found out that the devexpress functionality gave the same error! See the attached Indicium log in this matter.

So, bottom-line, after all it seems that this problem is not caused by the double website setup..

 

Is there any way to pinpoint when the issue arises? I’m assuming this is all done in a test environment and the production environment remains unaffected?

As a follow-up to the final solution coming from the topic above (a dedicated indicium for every website)e...]

Bit of a side-note: It does feels like there is a bit of a problem with the current set-up. If I understand correctly, you are using two Indicium instances.

There should only be one Indicium instance, the two subdomains should emerge from the routing, not via multiple Indicium instances.

To my knowledge, it is not even possible to run two indiciums on the same application pool, even when they use a different website. I would expect an error like HTTP Error 500.35 - ASP.NET Core does not support multiple apps in the same app pool or something.

Using two application pools may be possible but like it was mentioned in the other topic, they should not share the same files due to caching and logging. And this is not neccessary either when solving this via routing.

Hello @Richard Elderman,

This looks like an issue in Microsoft’s SqlClient library. This appears to be the same issue as the one you are having. One of the replies in that thread says that this issue occurs on Amazon RDS instances with Multi-AZ mode. Is this something that you have configured recently?

@Anne Buit this is indeed the case in our TEST environment.

Sorry for the unclarity about our current setup. Our current setup with two websites consists of:

  • two IIS sites
  • each site having its own application pool
  • each pool containing a single indicium
  • each indicium having its own source files

Due to the lack of time (prod deploy next wednesday) and the complexity of the rewriting solution in context to AWS ALB/ Elastic Beanstalk/IIS we have decided to use this setup for now. In the future when there is more time it is intended to investigate how to configure the redirection solution.

As for the devexpress issue, I have reconfigured our indicium/universal setup completely to the moment that the functionality last worked. Now it does not work due to the same error as in the previous indicium logs...

 

@Vincent Doppenberg thanks for your reply, good one! We have indeed recently configured RDS to multi-az mode…

Having read the link you sent, am I right that the solution, if any, must be implemented in Indicium's source code??

Hello @Richard Elderman,

Having read the link you sent, am I right that the solution, if any, must be implemented in Indicium's source code??

It’s a matter of updating a Microsoft library that Indicium uses to connect to the database. The issue was in Microsoft’s code and they appear to have solved it. I can update the package and release a hotfix for you.

However, since the issue appears to be related to “Failover” I have some doubts that this will be the full solution. Because it sounds like the connections fails, it tries to perform some kind of failover and then it crashes there. But I could be wrong, perhaps this is the full solution to your problem. At the very least I would expect a better error message after updating.

I will leave a reply here where the hotfix is ready, so you can try it. It will have version number 2023.1.13.3.

Hi @Vincent Doppenberg,

The hotfix will certainly help indeed, thanks!

I hope this is the full solution. We use multi-az but in such a way that the other database is only ready for fail over (mirroring). So no traffic is send to this second instance. Therefore I would expect that the fix by Microsoft also includes that in such a situation it is not needed, or maybe even somewhat forbidden, to check the state of the failover instance.

Hello @Richard Elderman,

The hotfix is now available in TCP.

Hi @Vincent Doppenberg,

We deployed the hotfix on our TEST environment. It has indeed solved the DevExpress issues!

Thanks for your quick reactions, and have a good weekend!

 

@Vincent Doppenberg @Richard Elderman Thanks a lot for going the extra mile late Friday afternoon/night and resolving this issue so quickly!

Terms & ConditionsCookie settings