[JBoss JIRA] (ISPN-5345) Allow eviction based on approximation of size compared to element count
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5345?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-5345:
--------------------------------
Summary: Allow eviction based on approximation of size compared to element count (was: Allow eviction for based on approximation of size compared to element count)
> Allow eviction based on approximation of size compared to element count
> -----------------------------------------------------------------------
>
> Key: ISPN-5345
> URL: https://issues.jboss.org/browse/ISPN-5345
> Project: Infinispan
> Issue Type: Enhancement
> Components: Eviction
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 8.0.0.Final
>
>
> It would be nice to have a bounded container that allows for eviction based on how much memory approximately the various arrays would take up.
> If possible we may even to enhance the data container to have a callback to provide a user specified way of calculating size for non byte[] values.
> This implementation would not know anything about duplicate references in the container and would count it double.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months
[JBoss JIRA] (ISPN-4574) PartitionHandling: consider less than numOwners partitions
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4574?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4574:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1147885|https://bugzilla.redhat.com/show_bug.cgi?id=1147885] from MODIFIED to CLOSED
> PartitionHandling: consider less than numOwners partitions
> ----------------------------------------------------------
>
> Key: ISPN-4574
> URL: https://issues.jboss.org/browse/ISPN-4574
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Reporter: Mircea Markus
> Assignee: Dan Berindei
> Priority: Critical
> Labels: partition_handling
> Fix For: 7.0.0.Beta2
>
>
> If the following two conditions are simultaneously met during a split brain:
> a) less than numOwners nodes leave
> b) two clusters are formed having that size
> Then both partitions would be considered as available. E.g. a cluster of 6 nodes with numOwners=4, with a split brain resulting in 3 and 3 nodes partitions.
> We should add some logic to prevent this situation, e.g. by requiring the remaining partition to have at least numOwners members.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months
[JBoss JIRA] (ISPN-5449) java.lang.ClassCastException: [B cannot be cast to org.infinispan.container.entries.CacheEntry
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5449?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-5449:
--------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/3475
> java.lang.ClassCastException: [B cannot be cast to org.infinispan.container.entries.CacheEntry
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-5449
> URL: https://issues.jboss.org/browse/ISPN-5449
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 7.2.1.Final
> Reporter: Enrico Olivelli
> Assignee: William Burns
> Fix For: 7.2.2.Final, 8.0.0.Alpha1
>
>
> Hi,
> I'm going to upgrade to Infinspan 7.2.1final but I got into a showstopper. This error occours very frequently and the cluster becomes not usable.
> In dev enviroment I'm using only Java HotRod clients and 3 Java HotRod Servers. When I put a "byte[]" in a cache then the following error occurs.
> Using only one Hotrod server the error does not occur.
> {code}
> ERROR interceptors.InvocationContextInterceptor: ISPN000136: Execution error
> java.lang.ClassCastException: [B cannot be cast to org.infinispan.container.entries.CacheEntry
> at org.infinispan.interceptors.compat.BaseTypeConverterInterceptor.visitGetCacheEntryCommand(BaseTypeConverterInterceptor.java:118)
> at org.infinispan.commands.read.GetCacheEntryCommand.acceptVisitor(GetCacheEntryCommand.java:39)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> at org.infinispan.commands.AbstractVisitor.visitGetCacheEntryCommand(AbstractVisitor.java:91)
> at org.infinispan.commands.read.GetCacheEntryCommand.acceptVisitor(GetCacheEntryCommand.java:39)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.getCacheEntry(CacheImpl.java:437)
> at org.infinispan.cache.impl.DecoratedCache.getCacheEntry(DecoratedCache.java:547)
> at org.infinispan.server.hotrod.CacheDecodeContext.get(CacheDecodeContext.scala:180)
> at org.infinispan.server.hotrod.HotRodDecoder.org$infinispan$server$hotrod$HotRodDecoder$$decodeKey(HotRodDecoder.scala:103)
> at org.infinispan.server.hotrod.HotRodDecoder$$anonfun$decode$1.apply$mcV$sp(HotRodDecoder.scala:48)
> at org.infinispan.server.hotrod.HotRodDecoder$$anon$1.run(HotRodDecoder.scala:206)
> at org.infinispan.server.hotrod.HotRodDecoder$$anon$1.run(HotRodDecoder.scala:205)
> at org.infinispan.security.Security.doAs(Security.java:143)
> at org.infinispan.server.hotrod.HotRodDecoder.wrapSecurity(HotRodDecoder.scala:205)
> at org.infinispan.server.hotrod.HotRodDecoder.decode(HotRodDecoder.scala:45)
> at io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:370)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:168)
> at org.infinispan.server.hotrod.HotRodDecoder.org$infinispan$server$core$transport$StatsChannelHandler$$super$channelRead(HotRodDecoder.scala:31)
> at org.infinispan.server.core.transport.StatsChannelHandler$class.channelRead(StatsChannelHandler.scala:32)
> at org.infinispan.server.hotrod.HotRodDecoder.channelRead(HotRodDecoder.scala:31)
> ....
> {code}
> Cache Server configuration:
> {code}
> Configuration wildcard = new ConfigurationBuilder()
> .locking().lockAcquisitionTimeout(lockAcquisitionTimeout)
> .concurrencyLevel(10000)
> .isolationLevel(IsolationLevel.READ_COMMITTED)
> .useLockStriping(true)
> .clustering()
> .cacheMode(CacheMode.DIST_SYNC)
> .l1().lifespan(l1ttl).enable()
> .hash().numOwners(numOwners)
> .capacityFactor(capacityFactor)
> .partitionHandling().enabled(false)
> .stateTransfer().awaitInitialTransfer(false)
> .timeout(initialTransferTimeout).fetchInMemoryState(false)
> .storeAsBinary().enabled(true)
> .storeKeysAsBinary(false).storeValuesAsBinary(false)
> .jmxStatistics().enable()
> .unsafe().unreliableReturnValues(true) // put e remove non ritornano il valore precedente, tanto a noi non interessa
> .compatibility().enable()
> .build();
> {code}
> Hotrod Endpoint:
> {code}
> HotRodServerConfigurationBuilder configBuilder = new HotRodServerConfigurationBuilder()
> .host(address)
> .port(port);
> hotrodserver.start(configBuilder
> .build(),
> manager);
> {code}
> Client side config:
> {code}
> org.infinispan.client.hotrod.configuration.ConfigurationBuilder clientBuilder = new org.infinispan.client.hotrod.configuration.ConfigurationBuilder().forceReturnValues(false);
> clientBuilder.nearCache().mode(NearCacheMode.LAZY).maxEntries(10000);
> //(for each server....)
> clientBuilder.addServer().host(serveraddress).port(serverport);
> {code}
> {code}
> RemoteCacheManager remoteCacheManager = new RemoteCacheManager(clientBuilder.build());
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months
[JBoss JIRA] (ISPN-5449) java.lang.ClassCastException: [B cannot be cast to org.infinispan.container.entries.CacheEntry
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5449?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-5449:
--------------------------------
Fix Version/s: 8.0.0.Alpha1
> java.lang.ClassCastException: [B cannot be cast to org.infinispan.container.entries.CacheEntry
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-5449
> URL: https://issues.jboss.org/browse/ISPN-5449
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 7.2.1.Final
> Reporter: Enrico Olivelli
> Assignee: William Burns
> Fix For: 7.2.2.Final, 8.0.0.Alpha1
>
>
> Hi,
> I'm going to upgrade to Infinspan 7.2.1final but I got into a showstopper. This error occours very frequently and the cluster becomes not usable.
> In dev enviroment I'm using only Java HotRod clients and 3 Java HotRod Servers. When I put a "byte[]" in a cache then the following error occurs.
> Using only one Hotrod server the error does not occur.
> {code}
> ERROR interceptors.InvocationContextInterceptor: ISPN000136: Execution error
> java.lang.ClassCastException: [B cannot be cast to org.infinispan.container.entries.CacheEntry
> at org.infinispan.interceptors.compat.BaseTypeConverterInterceptor.visitGetCacheEntryCommand(BaseTypeConverterInterceptor.java:118)
> at org.infinispan.commands.read.GetCacheEntryCommand.acceptVisitor(GetCacheEntryCommand.java:39)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> at org.infinispan.commands.AbstractVisitor.visitGetCacheEntryCommand(AbstractVisitor.java:91)
> at org.infinispan.commands.read.GetCacheEntryCommand.acceptVisitor(GetCacheEntryCommand.java:39)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.getCacheEntry(CacheImpl.java:437)
> at org.infinispan.cache.impl.DecoratedCache.getCacheEntry(DecoratedCache.java:547)
> at org.infinispan.server.hotrod.CacheDecodeContext.get(CacheDecodeContext.scala:180)
> at org.infinispan.server.hotrod.HotRodDecoder.org$infinispan$server$hotrod$HotRodDecoder$$decodeKey(HotRodDecoder.scala:103)
> at org.infinispan.server.hotrod.HotRodDecoder$$anonfun$decode$1.apply$mcV$sp(HotRodDecoder.scala:48)
> at org.infinispan.server.hotrod.HotRodDecoder$$anon$1.run(HotRodDecoder.scala:206)
> at org.infinispan.server.hotrod.HotRodDecoder$$anon$1.run(HotRodDecoder.scala:205)
> at org.infinispan.security.Security.doAs(Security.java:143)
> at org.infinispan.server.hotrod.HotRodDecoder.wrapSecurity(HotRodDecoder.scala:205)
> at org.infinispan.server.hotrod.HotRodDecoder.decode(HotRodDecoder.scala:45)
> at io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:370)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:168)
> at org.infinispan.server.hotrod.HotRodDecoder.org$infinispan$server$core$transport$StatsChannelHandler$$super$channelRead(HotRodDecoder.scala:31)
> at org.infinispan.server.core.transport.StatsChannelHandler$class.channelRead(StatsChannelHandler.scala:32)
> at org.infinispan.server.hotrod.HotRodDecoder.channelRead(HotRodDecoder.scala:31)
> ....
> {code}
> Cache Server configuration:
> {code}
> Configuration wildcard = new ConfigurationBuilder()
> .locking().lockAcquisitionTimeout(lockAcquisitionTimeout)
> .concurrencyLevel(10000)
> .isolationLevel(IsolationLevel.READ_COMMITTED)
> .useLockStriping(true)
> .clustering()
> .cacheMode(CacheMode.DIST_SYNC)
> .l1().lifespan(l1ttl).enable()
> .hash().numOwners(numOwners)
> .capacityFactor(capacityFactor)
> .partitionHandling().enabled(false)
> .stateTransfer().awaitInitialTransfer(false)
> .timeout(initialTransferTimeout).fetchInMemoryState(false)
> .storeAsBinary().enabled(true)
> .storeKeysAsBinary(false).storeValuesAsBinary(false)
> .jmxStatistics().enable()
> .unsafe().unreliableReturnValues(true) // put e remove non ritornano il valore precedente, tanto a noi non interessa
> .compatibility().enable()
> .build();
> {code}
> Hotrod Endpoint:
> {code}
> HotRodServerConfigurationBuilder configBuilder = new HotRodServerConfigurationBuilder()
> .host(address)
> .port(port);
> hotrodserver.start(configBuilder
> .build(),
> manager);
> {code}
> Client side config:
> {code}
> org.infinispan.client.hotrod.configuration.ConfigurationBuilder clientBuilder = new org.infinispan.client.hotrod.configuration.ConfigurationBuilder().forceReturnValues(false);
> clientBuilder.nearCache().mode(NearCacheMode.LAZY).maxEntries(10000);
> //(for each server....)
> clientBuilder.addServer().host(serveraddress).port(serverport);
> {code}
> {code}
> RemoteCacheManager remoteCacheManager = new RemoteCacheManager(clientBuilder.build());
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months
[JBoss JIRA] (ISPN-5449) java.lang.ClassCastException: [B cannot be cast to org.infinispan.container.entries.CacheEntry
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5449?page=com.atlassian.jira.plugin.... ]
William Burns reassigned ISPN-5449:
-----------------------------------
Assignee: William Burns (was: Galder Zamarreño)
> java.lang.ClassCastException: [B cannot be cast to org.infinispan.container.entries.CacheEntry
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-5449
> URL: https://issues.jboss.org/browse/ISPN-5449
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 7.2.1.Final
> Reporter: Enrico Olivelli
> Assignee: William Burns
> Fix For: 7.2.2.Final
>
>
> Hi,
> I'm going to upgrade to Infinspan 7.2.1final but I got into a showstopper. This error occours very frequently and the cluster becomes not usable.
> In dev enviroment I'm using only Java HotRod clients and 3 Java HotRod Servers. When I put a "byte[]" in a cache then the following error occurs.
> Using only one Hotrod server the error does not occur.
> {code}
> ERROR interceptors.InvocationContextInterceptor: ISPN000136: Execution error
> java.lang.ClassCastException: [B cannot be cast to org.infinispan.container.entries.CacheEntry
> at org.infinispan.interceptors.compat.BaseTypeConverterInterceptor.visitGetCacheEntryCommand(BaseTypeConverterInterceptor.java:118)
> at org.infinispan.commands.read.GetCacheEntryCommand.acceptVisitor(GetCacheEntryCommand.java:39)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> at org.infinispan.commands.AbstractVisitor.visitGetCacheEntryCommand(AbstractVisitor.java:91)
> at org.infinispan.commands.read.GetCacheEntryCommand.acceptVisitor(GetCacheEntryCommand.java:39)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.getCacheEntry(CacheImpl.java:437)
> at org.infinispan.cache.impl.DecoratedCache.getCacheEntry(DecoratedCache.java:547)
> at org.infinispan.server.hotrod.CacheDecodeContext.get(CacheDecodeContext.scala:180)
> at org.infinispan.server.hotrod.HotRodDecoder.org$infinispan$server$hotrod$HotRodDecoder$$decodeKey(HotRodDecoder.scala:103)
> at org.infinispan.server.hotrod.HotRodDecoder$$anonfun$decode$1.apply$mcV$sp(HotRodDecoder.scala:48)
> at org.infinispan.server.hotrod.HotRodDecoder$$anon$1.run(HotRodDecoder.scala:206)
> at org.infinispan.server.hotrod.HotRodDecoder$$anon$1.run(HotRodDecoder.scala:205)
> at org.infinispan.security.Security.doAs(Security.java:143)
> at org.infinispan.server.hotrod.HotRodDecoder.wrapSecurity(HotRodDecoder.scala:205)
> at org.infinispan.server.hotrod.HotRodDecoder.decode(HotRodDecoder.scala:45)
> at io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:370)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:168)
> at org.infinispan.server.hotrod.HotRodDecoder.org$infinispan$server$core$transport$StatsChannelHandler$$super$channelRead(HotRodDecoder.scala:31)
> at org.infinispan.server.core.transport.StatsChannelHandler$class.channelRead(StatsChannelHandler.scala:32)
> at org.infinispan.server.hotrod.HotRodDecoder.channelRead(HotRodDecoder.scala:31)
> ....
> {code}
> Cache Server configuration:
> {code}
> Configuration wildcard = new ConfigurationBuilder()
> .locking().lockAcquisitionTimeout(lockAcquisitionTimeout)
> .concurrencyLevel(10000)
> .isolationLevel(IsolationLevel.READ_COMMITTED)
> .useLockStriping(true)
> .clustering()
> .cacheMode(CacheMode.DIST_SYNC)
> .l1().lifespan(l1ttl).enable()
> .hash().numOwners(numOwners)
> .capacityFactor(capacityFactor)
> .partitionHandling().enabled(false)
> .stateTransfer().awaitInitialTransfer(false)
> .timeout(initialTransferTimeout).fetchInMemoryState(false)
> .storeAsBinary().enabled(true)
> .storeKeysAsBinary(false).storeValuesAsBinary(false)
> .jmxStatistics().enable()
> .unsafe().unreliableReturnValues(true) // put e remove non ritornano il valore precedente, tanto a noi non interessa
> .compatibility().enable()
> .build();
> {code}
> Hotrod Endpoint:
> {code}
> HotRodServerConfigurationBuilder configBuilder = new HotRodServerConfigurationBuilder()
> .host(address)
> .port(port);
> hotrodserver.start(configBuilder
> .build(),
> manager);
> {code}
> Client side config:
> {code}
> org.infinispan.client.hotrod.configuration.ConfigurationBuilder clientBuilder = new org.infinispan.client.hotrod.configuration.ConfigurationBuilder().forceReturnValues(false);
> clientBuilder.nearCache().mode(NearCacheMode.LAZY).maxEntries(10000);
> //(for each server....)
> clientBuilder.addServer().host(serveraddress).port(serverport);
> {code}
> {code}
> RemoteCacheManager remoteCacheManager = new RemoteCacheManager(clientBuilder.build());
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months
[JBoss JIRA] (ISPN-5293) Create generic execution framework from EntryIterator
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5293?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-5293:
-------------------------------------
I was planning on having something for the first and second points. I was thinking that either asking for specific segments or specific keys would cover mostly the last point. But it depends if I find that the distexec framework would use this or not.
> Create generic execution framework from EntryIterator
> -----------------------------------------------------
>
> Key: ISPN-5293
> URL: https://issues.jboss.org/browse/ISPN-5293
> Project: Infinispan
> Issue Type: Feature Request
> Components: Distributed Execution and Map/Reduce
> Reporter: William Burns
> Assignee: William Burns
>
> This framework could be used to power a segment aware map/reduce framework and other events that require execution across the cluster.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months
[JBoss JIRA] (ISPN-5477) Compatibility with L1 can lead to wrong return type
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5477?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-5477:
-----------------------------------
Status: Open (was: New)
> Compatibility with L1 can lead to wrong return type
> ---------------------------------------------------
>
> Key: ISPN-5477
> URL: https://issues.jboss.org/browse/ISPN-5477
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 7.2.1.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.2.2.Final
>
>
> Currently, when using compatibility mode with distributed caches, it is possible for users to store keys using embedded API which hash differently to when the same key is access via remote API. This is due to the differences in source data. For embedded, the source object is the POJO, whereas for remote, the source object is the byte[] format of the pojo.
> When using such keys, remote APIs might go to a node which is not owner, leading to a remote get. When two gets are executed, the first of which results in L1 entry being added to the container, the second get result in exceptions such as this on the client:
> {code}
> java.lang.ClassCastException: [B cannot be cast to xxx....
> {code}
> This is due to over eager unboxing by the BaseTypeConverterInterceptor. I discovered this while investigating ISPN-5449.
> It would be ideal to not have scenarios where there are diverging keys but for that, clients would need to know when compatibility is enabled, which currently is not known by the clients. Maybe this could be negotiated with the ping command?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months
[JBoss JIRA] (ISPN-5477) Compatibility with L1 can lead to wrong return type
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5477?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-5477:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/3476
> Compatibility with L1 can lead to wrong return type
> ---------------------------------------------------
>
> Key: ISPN-5477
> URL: https://issues.jboss.org/browse/ISPN-5477
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 7.2.1.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.2.2.Final
>
>
> Currently, when using compatibility mode with distributed caches, it is possible for users to store keys using embedded API which hash differently to when the same key is access via remote API. This is due to the differences in source data. For embedded, the source object is the POJO, whereas for remote, the source object is the byte[] format of the pojo.
> When using such keys, remote APIs might go to a node which is not owner, leading to a remote get. When two gets are executed, the first of which results in L1 entry being added to the container, the second get result in exceptions such as this on the client:
> {code}
> java.lang.ClassCastException: [B cannot be cast to xxx....
> {code}
> This is due to over eager unboxing by the BaseTypeConverterInterceptor. I discovered this while investigating ISPN-5449.
> It would be ideal to not have scenarios where there are diverging keys but for that, clients would need to know when compatibility is enabled, which currently is not known by the clients. Maybe this could be negotiated with the ping command?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months