[JBoss JIRA] (ISPN-8566) Rest server doesn't handle wildcards in the Accept header
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-8566?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-8566:
------------------------------------
Description:
Typically a browser automatically adds multiple mime types in the accept header, like:
"text/html, application/xhtml+xml,\*/\*"
But when requesting a document in a cache encoded with protostream with the headers above, the response is
"Cannot find transcoder between application/xml and application/x-protostream"
was:
Typically a browser automatically adds multiple mime types in the accept header, like:
"text/html, application.xhtml+xml,\*/\*"
But when requesting a document in a cache encoded with protostream with the headers above, the response is
"Cannot find transcoder between application/xml and application/x-protostream"
> Rest server doesn't handle wildcards in the Accept header
> ---------------------------------------------------------
>
> Key: ISPN-8566
> URL: https://issues.jboss.org/browse/ISPN-8566
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.2.0.Beta1, 9.1.3.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 9.2.0.Final, 9.1.4.Final
>
>
> Typically a browser automatically adds multiple mime types in the accept header, like:
> "text/html, application/xhtml+xml,\*/\*"
> But when requesting a document in a cache encoded with protostream with the headers above, the response is
> "Cannot find transcoder between application/xml and application/x-protostream"
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (ISPN-8611) Caching and shared memory default service names too long
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-8611?page=com.atlassian.jira.plugin.... ]
Martin Gencur updated ISPN-8611:
--------------------------------
Summary: Caching and shared memory default service names too long (was: Caching and shared memory service names too long)
> Caching and shared memory default service names too long
> --------------------------------------------------------
>
> Key: ISPN-8611
> URL: https://issues.jboss.org/browse/ISPN-8611
> Project: Infinispan
> Issue Type: Bug
> Components: Cloud
> Reporter: Martin Gencur
>
> The default name for the application is "caching-service-app" and "shared-memory-service-app" respectively.
> The persistent volume claim (for StatefulSets) is called ${APPLICATION_NAME}-data.
> Now when I use e.g. GlusterFS for persistent volumes and deploy this application, a new service is created called "glusterfs-dynamic-caching-service-app-data-caching-service-app-0" (or "glusterfs-dynamic-shared-memory-service-app-data-shared-memory-service-app-0"
> However, the maximum length of service name is 63 chars. And the persistent volume claim fails with: {code}Failed to provision volume with StorageClass "gluster-container": glusterfs: create volume err: failed to create endpoint/service <nil>.{code}
> When the name whole name gets under 63 characters the volume claim is created successfully.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (ISPN-8611) Caching and shared memory service names too long
by Martin Gencur (JIRA)
Martin Gencur created ISPN-8611:
-----------------------------------
Summary: Caching and shared memory service names too long
Key: ISPN-8611
URL: https://issues.jboss.org/browse/ISPN-8611
Project: Infinispan
Issue Type: Bug
Components: Cloud
Reporter: Martin Gencur
The default name for the application is "caching-service-app" and "shared-memory-service-app" respectively.
The persistent volume claim (for StatefulSets) is called ${APPLICATION_NAME}-data.
Now when I use e.g. GlusterFS for persistent volumes and deploy this application, a new service is created called "glusterfs-dynamic-caching-service-app-data-caching-service-app-0" (or "glusterfs-dynamic-shared-memory-service-app-data-shared-memory-service-app-0"
However, the maximum length of service name is 63 chars. And the persistent volume claim fails with: {code}Failed to provision volume with StorageClass "gluster-container": glusterfs: create volume err: failed to create endpoint/service <nil>.{code}
When the name whole name gets under 63 characters the volume claim is created successfully.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (ISPN-8566) Rest server doesn't handle wildcards in the Accept header
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-8566?page=com.atlassian.jira.plugin.... ]
Work on ISPN-8566 started by Gustavo Fernandes.
-----------------------------------------------
> Rest server doesn't handle wildcards in the Accept header
> ---------------------------------------------------------
>
> Key: ISPN-8566
> URL: https://issues.jboss.org/browse/ISPN-8566
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.2.0.Beta1, 9.1.3.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 9.2.0.Final, 9.1.4.Final
>
>
> Typically a browser automatically adds multiple mime types in the accept header, like:
> "text/html, application.xhtml+xml,\*/\*"
> But when requesting a document in a cache encoded with protostream with the headers above, the response is
> "Cannot find transcoder between application/xml and application/x-protostream"
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (ISPN-8609) Hot Rod: share the server list globally during failover
by Radim Vansa (JIRA)
Radim Vansa created ISPN-8609:
---------------------------------
Summary: Hot Rod: share the server list globally during failover
Key: ISPN-8609
URL: https://issues.jboss.org/browse/ISPN-8609
Project: Infinispan
Issue Type: Enhancement
Components: Remote Protocols
Affects Versions: 9.2.0.Beta1
Reporter: Radim Vansa
Right now we keep list separate topologies for each cache in TopologyInfo. Suppose we have an active cache (many requests going there) and inactive (request once in a couple of hours). During complete cluster update (when all old servers are stopped and new ones booted) the active cache will get the server list updated, but the inactive cache is not informed about this.
With current protocol we cannot piggyback information about server liveness and the cache might be just stopped - therefore we cannot simply remove the server from the other caches.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years