Uploaded image for project: 'JBoss Cache'
  1. JBoss Cache
  2. JBCACHE-1123

Non-streaming state transfer failures not properly handled

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: 2.0.0.CR3
    • Fix Version/s: 2.0.0.GA
    • Component/s: Clustering
    • Labels:
      None

      Description

      I'm noticing spurious WARN messages in the logs from JGroups when caches do partial state transfers and the cache being requested doesn't have the target node available:

      WARN [org.jgroups.protocols.pbcast.STATE_TRANSFER] state received from 192.168.1.164:4655 is null, will return null state to application

      Looking at the JBC state transfer code, particularly StateTransferManager.getState(ObjectOutputStream out, Fqn fqn, long timeout, boolean force, boolean suppressErrors), the apparent intent is for a boolean 'false' and a CacheException to be written to the stream, serialized, and returned to the requestor. The CacheException is also thrown.

      This is breaking in CacheImpl.MessageListenerAdaptor.getState() and getState(String):

      try

      { ExposedByteArrayOutputStream baos = new ExposedByteArrayOutputStream(16 * 1024); out = new MarshalledValueOutputStream(baos); getStateTransferManager().getState(out, Fqn.fromString(sourceRoot), configuration.getStateRetrievalTimeout(), true, true); result = baos.getRawBuffer(); }

      catch (Throwable t)

      { stateProducingFailed(t); }

      finally

      { Util.close(out); }

      return result;

      The CacheException is thrown from StateTransferManager.getState(). Therefore "result = baos.getRawBuffer();" is never invoked. Therefore the returned state is null, leading to the WARN on the recipient. This seems contrary to the intent to propagate the boolean + exception to the recipient.

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                vblagojevic Vladimir Blagojevic
                Reporter:
                brian.stansberry Brian Stansberry
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: