Failure when trying to delete service key of s3 storage service - swisscomdev

Deleting a service key fails with internal server error.
The following command produces the error:
cf dsk -f storage storage-keys
Deleting key storage-keys for service instance storage as user...
FAILED
Server error, status code: 502, error code: 10001, message: Service broker failed to delete service binding for instance storage: Service broker error: Internal Server Error
The error seems to be specific to this service key. It is a service key of a S3 storage service. I tried for several days with always the same error result. Withing the same time span deleting othe service keys (of Maria DB services) worked as expected.

This is a Swisscom specific problem that we have experienced as well. The only way to resolve the error was to send a direct support request via this form:
https://developer.swisscom.com/support
They will then proceed to manually delete the binding and ideally fix the related server error.

Related

Keycloak Cached clientScope not found

Getting repeatedly this error in Keycloak logs.
Attached below are the logs for reference:
The said client scope is not found if I try to search the same under Keycloak admin console too.
2022-09-22 04:04:12,718 ERROR [org.key.ser.err.KeycloakErrorHandler] (executor-thread-610) Uncaught server error: java.lang.IllegalStateException: Cached clientScope not found: 1e84ef04-9ef9-44fe-b1bd-f45e6d4 at org.keycloak.models.cache.infinispan.RealmAdapter.lambda$getClientScopesStream$3(RealmAdapter.java:1495) at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) at java.base/java.util.ArrayList$ArrayListSpliterator.tryAdvance(ArrayList.java:1632) at
Steps to recreate:
Create client scope and attached to a client
Remove client scope attached with a client
Delete client scope
On the occurrence of this issue, I see well-known and many other endpoints to start giving 500 as they seem to be fetching cached scoped and doing certain validation
Any configuration miss that needs to be considered?

Connecting to AWS Managed Cassandra with Perl

I am trying to connect to AWS Managed Cassandra using Perl. It's not working due to a vague error Error 0: Internal Server Error.
Using the DBD::Cassandra Library, I can connect to self hosted Cassandra clusters, but not AWS Cassandra. I think I have the AWS Root CA correct because it verifies with openssl s_client -connect cassandra.us-east-1.amazonaws.com:9142
DBI->connect("dbi:Cassandra:host=cassandra.us-east-1.amazonaws.com;port=9142;tls=1;keyspace=keyspace",
"**username**", "**password**");
The error response from the connection is
Unable to connect to any Cassandra server.
Last error: On cassandra.us-east-1.amazonaws.com:
Error 0: Internal Server Error
I can also connect using the cqlsh client and verified that the connection details are correct.
Any hints or a working example would be very helpful.
The issue appears to be setting the keyspace. Doing this either on the connection or subsequently with use keyspace results in a Error 0: Internal Server Error response from the server.
Also note that AWS Managed Cassandra only supports consistency local_quorum. The following will result in a valid connection:
DBI->connect("dbi:Cassandra:host=cassandra.us-east-1.amazonaws.com;
port=9142;tls=1;consistency=local_quorum",
"**username**", "**password**");
Since there are issues setting the keyspace, tables must be referenced using keyspace.tablename in queries.

Connection to a S3 instance using a service-connector

I'm trying to create a service-connector to my s3 instance like this:
cf service-connector 13001 mybucketname.ds31s3.swisscom.com:443
But I get the following error:
Server-Error 403: Check of security groups failed (no access)
I have created my service key according to this documentation.
Connecting to my MongoDB works perfectly using a service connector.
You can access Swisscom's S3 directly without the service connector.
The error message suggests that your current org and space do no have access to the S3. This is usually the case is there is no app-binding for that service in the current space. Please check whether you created your service key in the right org and space.
There was a misconfiguration due to security changes. We fixed the issue, so connecting to s3 with the service-connector should now work.

ServiceProxy throws ProtocolException, communication is not restored on retrying

We are seeing ProtocolExceptions while communicating with a service running in the cluster. The message and InnerException message:
System.ServiceModel.ProtocolException: You have tried to create a channel to a service that does not support .Net Framing.
---> System.IO.InvalidDataException: Expected record type 'PreambleAck', found '145'.
This service is running on a local dev cluster, and the exception is thrown after communicating successfully with the service.
The code that we use for communicating is:
var eventHandlerServiceClient = ServiceProxy.Create<IEventHandlerService>(eventHandlerTypeName, new Uri(ServiceFabricSettings.EventHandlerServiceName));
return await eventHandlerServiceClient.GetQueueLength();
We have retry logic (with increasing delay's between the attempts). But this call never succeeds. So it looks like the service is in a fault state and cannot recover from it.
Update
We are also seeing the following errors in the logs:
connection 0x1B6F9EB0 localhost:64002-[::1]:50376 target 0x1B64F3C0: invalid frame: length=0x1000100,type=514,header=28278,check=0x742E7465
Update 14-12-2015
If this ProtocolException is thrown, retries don't help. Even after hours of waiting, it still fails.
We log the endpoint address with
var spr = ServicePartitionResolver.GetDefault();
var x = await spr.ResolveAsync(new Uri(ServiceFabricSettings.EventHandlerServiceName),
eventHandlerTypeName,
new CancellationToken());
var endpointAddress = x.GetEndpoint().Address;
The resolved endpoint looks like
{"Endpoints":{"":"net.tcp:\/\/localhost:57999\/d6782e21-87c0-40d1-a505-ec6f64d586db\/a00e6931-aee6-4c6d-868a-f8003864a216-130945476153695343"}}
This endpoint is the same as reported by the Service Fabric Explorer.
From our logs seen, it seems that this service is working (it is reachable via another API method), but this specific call never succeeds.
This typically indicate mismatched communication stack on the service and client side. Once the service is up and running, check the endpoint of the service replica via Service Fabric Explorer. If that seems fine, check that the client is connecting to the right service. Resolve the partition using the ServicePartitionResolver (https://msdn.microsoft.com/en-us/library/azure/microsoft.servicefabric.services.servicepartitionresolver.aspx), passing the same arguments that you pass to ServiceProxy.
I'm seeing the same sort of errors. Just looking at my code, I'm caching an actorproxy. I'm going to change that and remove the caching in case the cache is referencing an old instance of the service.
That appears to have fixed my issues. I'm guessing that the proxy caches the reference once it has been used and if the service changes, that reference is out of date.

SQLDB status code 500

I received a FAILED Server error, status code: 500, error code: 10001,
message: Service broker error : {"description"=>"Service Broker provisioned at this url state is not operational 10002"} message, when trying to create a new SQLDB service instance.
What is the issue?
I was able to confirm that there was a brief issue earlier with the "Free" plan but it has since been resolved.
I was able to create a service successfully from the CF command line:
$ cf create-service sqldb sqldb_free randalstTestSQLDB515
Creating service randalstTestSQLDB515 in org johndoe#myemail.com /
space dev as johndoe#myemail.com...
OK
Try to create the service from the command line using the following syntax:
$ cf create-service sqldb sqldb_small mySQLDB
where
The first attribute sqldb is the service name.
The second attribute is the plan, either sqldb_small, sqldb_free, or sqldb_premium.
The last attribute mySQLDB is the unique name that you are giving to this service instance.