[JBoss JIRA] (ISPN-3752) capacityFactor is not effective
by Takayoshi Kimura (JIRA)
Takayoshi Kimura created ISPN-3752:
--------------------------------------
Summary: capacityFactor is not effective
Key: ISPN-3752
URL: https://issues.jboss.org/browse/ISPN-3752
Project: Infinispan
Issue Type: Bug
Components: Distributed Cache
Affects Versions: 6.0.0.Final
Reporter: Takayoshi Kimura
Assignee: Dan Berindei
The capacityFactor is not effective because the ClusterCacheStatus.addMember() uses its own, local joinInfo and doesn't use joiner's capacityFactor on method parameter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (ISPN-3503) Upstream server build doesn't include protobuf libraries in client/hotrod/java directory
by Michal Linhard (JIRA)
[ https://issues.jboss.org/browse/ISPN-3503?page=com.atlassian.jira.plugin.... ]
Michal Linhard commented on ISPN-3503:
--------------------------------------
This doesn't seem to be an issue anymore on current master, the protobuf libraries aren't included, but hotrod client can somehow live without them...
I think at the time of reporting this, I couldn't make a hotrod call without the protobuf library.
> Upstream server build doesn't include protobuf libraries in client/hotrod/java directory
> ----------------------------------------------------------------------------------------
>
> Key: ISPN-3503
> URL: https://issues.jboss.org/browse/ISPN-3503
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 6.0.0.Alpha4
> Reporter: Michal Linhard
> Assignee: Tristan Tarrant
>
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/user/mlinhard@REDHAT.COM...
> This is the contents of the client/hotrod/java folder:
> {code}
> adding: infinispan-server-6.0.x/client/hotrod/java/jboss-marshalling-river-1.3.15.GA.jar (deflated 8%)
> adding: infinispan-server-6.0.x/client/hotrod/java/jboss-marshalling-1.3.15.GA.jar (deflated 12%)
> adding: infinispan-server-6.0.x/client/hotrod/java/jboss-logging-3.1.1.GA.jar (deflated 10%)
> adding: infinispan-server-6.0.x/client/hotrod/java/commons-pool-1.6.jar (deflated 8%)
> adding: infinispan-server-6.0.x/client/hotrod/java/infinispan-commons-6.0.0-SNAPSHOT.jar (deflated 13%)
> adding: infinispan-server-6.0.x/client/hotrod/java/infinispan-client-hotrod-6.0.0-SNAPSHOT.jar (deflated 12%)
> {code}
> JDG 6.2.0.DR4 doesn't have this problem, but this affects my regression testing where I use builds from latest upstream snapshots
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (ISPN-3691) Make client side Connection refused error TRACE
by Michal Linhard (JIRA)
[ https://issues.jboss.org/browse/ISPN-3691?page=com.atlassian.jira.plugin.... ]
Michal Linhard updated ISPN-3691:
---------------------------------
Affects Version/s: 6.0.0.Final
> Make client side Connection refused error TRACE
> -----------------------------------------------
>
> Key: ISPN-3691
> URL: https://issues.jboss.org/browse/ISPN-3691
> Project: Infinispan
> Issue Type: Feature Request
> Affects Versions: 6.0.0.CR1, 6.0.0.Final
> Reporter: Michal Linhard
> Assignee: Mircea Markus
> Priority: Minor
>
> After solving ISPN-3454, it seems that only remaining client-side error during node crashes is "Connection refused":
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/RESILIENCE...
> This has been reported before as ISPN-1794 or ISPN-1119, but actually it seems like it reappeared in different place.
> Sorry for not reporting sooner, I got used to ignoring some of the long-open cosmetic low-prio log message issues, that I forgot about this one...
> The issue here is that these "Connection refused" problems are retry-able, so the client log shouldn't contain error.
> Maybe only some info level message about failing over to different node. But that's actually already reported by the INFO level messages about the topology changes
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month