---

Hallo,

Verwendet von euch irgendwer "Store and Forward with side caching"?
Habe dazu folgende Frage:

OOTB arbeitet der S&F-Mechanismus ohne side caching.
D.h.: Die Daten werde vom Default-Local-Volume in der Remote-Group zum richtigen Volume übertragen aber
in der Remote-Group nicht mehr gecacht
> somit muss beim nächsten Ladevorgang die Datei wieder über das WAN übertragen werden.

Habe in der TC-Doku folgenden Artikel gefunden:
"Using a default local volume with side caching"

"Without side caching configured, the file is only cached after the initial download. With side caching enabled, after the file is transferred to the final destination volume, it is automatically side cached to the defined exit FSCs in the remote FSC group."
> Enable side caching by explicitly defining exit FSCs in the fmsmaster.xml.

Habe diesen <exitfsc....> Eintrag im fmsmaster.xml gemacht, doch leider funktioniert das side caching nicht.
> Beim Speichern werden die Daten nicht gecacht.

------------------
MfG Michael

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hi Michael,

- hast du den Dispatcher am laufen für das Prepopulate?
  - FMSTransfer und PopulateFSC
- auf der gegenueberliegenden Seite ist da der Coporate Server mit Teamcenter Foundation und FMS Server Cache installiert?
- ist dort der Non-Master FSC korrekt angegeben?
- ist auf eurem Server der Non-Master FSC und der Master FSC korrekt angegeben?
- Ist auf den Clients die FSC Client Map korrekt (Non-Master)
- und sehr wichtigt ist ein StoreVolume definiert (Eigenens Volume)

------------------
Gruß

Michael

have you tried turning it off and on again

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Michael,

Danke für deine Antwort.

Dispatcher und FMSTransfer laufen
> der Store&Forward Mechanismus funktioniert auch einwandfrei, lediglich das Cachen beim Speichern funktioniert nicht.

Wenn ich S&F deaktiviere, dann wächst der Read- und Write-Cache in der Remote Group, somit muss die ganze FMS-Konfiguration (Master, Non-Master, client-mapping,...) richtig sein.

PopulateFSC hab ich nicht, denke dass ich diesen auch nicht benötige, da ich wirklich nur die Daten cachen will die übertragen werden.

Werde noch einige Tests mit dem WholeFileCache durchführen, da dieser momentan bei uns deaktiviert ist.
Welche Vor- bzw. Nachteile hat dieser Cache?

------------------
MfG Michael

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,

bei uns ist es so, das beim speichern mittels Store&Forward keine Dateien im FSC WriteCache oder FSC ReadCache landen. Erst nachdem durch den Dispatcher der fmstransfer geplant (Scheduled) wird, findest Du die entsprechende Datei im FSC ReadCache welcher über den exitfsc definiert wurde.

Der Write Cache wird nur bei Speichervorgängen ohne Beteiligung Store&Forward (User hat kein Default Local Volume) zumindest bei uns genutzt, hier schlägt dann das clientmap der FMS Konfig zu.

Vorteil vom WholeFileCache auf FSC: 
Soweit ich mich erinnere, kann man den WholeFileCache mittels Tool (FSCWholeFileCacheUtil) auf einen zweiten FSC-Server z.B. in der Site synchronisieren/kopieren. Dadurch verliert man falls der FSCCache korrupt ist (kann ja mal passieren) oder man den FSC umziehen will, nicht den Inhalt von diesen.

Gruß
Roland

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Roland,

Danke für deine Antwort.
Habe jetzt meine Tests mit dem WholeFileCache abgeschlossen und siehe da mit diesem Cache funktioniert es.
Habe an der Konfiguration nichts geändert, außer dass ich diesen Cache aktiviert habe.
Nach der S&F Übertragung liegt das File auch definitiv in diesem WholeFileCache.

Leider erfährt man in der Doku nicht sehr viel über die Arbeitsweise der Caches, Vor- und Nachteile, Einsatzgebiete, usw…
Für den WholeFileCache sind lediglich nur die Parameter bzw. ein Utility beschrieben.

Für mich wäre sehr interessant, wie sich die Caches wenn beide (WholeFileCache und SegmentCache) aktiviert sind verhalten.
Wann wird in welchen Cache geschrieben?

------------------
MfG Michael

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

@Roland

Eine Frage hätte ich noch an dich.
Ihr verwendet ja auch den S&F-Mechanismus und somit auch den fmstransfer-Translator.
Weiters verwendet ihr NX und Catia und wahrscheinlich dann auch den catiatojt-Translator.

Habt ihr auch das Problem mit der Priority der fmstransfer-Requests?
Bei diesen Requests kann man leider die Priority nicht festlegen, diese haben standardmäßig den Wert Low.
Andere Requests (catiatojt,...) dagegen haben eine höhere Priority (Medium oder High)
und somit werden diese vor den fmstranfer-Requests abgearbeitet.

> es kann dann vorkommen, dass ein fmstransfer-Request sehr lange braucht bis er abgearbeitet wird.
Für uns ist dies aber einer der wichtigsten Requests.

Habt ihr da einen work-around gefunden, bzw. wie geht ihr mit diesem Problem um?
zB: die Priority aller Requests auf Low zu setzen.

------------------
MfG Michael

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Michael,

stimmt ist ein Problem.
Wir haben uns so beholfen.

a) Wir nutzen bei uns die automatische JT-Translation beim Speichern von Catia-Files nicht.

b) Die Anwender haben die Möglichkeit, über die Dispatcher Client Konsole bei Bedarf dringend benötigte JT-Files zu erzeugen.

c) Haben wir einen bzw. mehrere Batch-Läufe generiert, der eine Teamcenter Query absetzt und als Results nur z.B. modifizierte Catia Files für einen definierten Zeitraum mit definierten "Arbeitsstände" und bei denen die Datasets nicht mehr im Default Local Volume liegen, also schon über Store&Forward transferiert wurden.

Dieses Ergebnis schicken wir dann in den Dispatcher (dispatcher_create_rqst) zur Generierung von JTŽs. Hier kann man dann auch noch die Priority für den Request unabhängig der TC-Prefernence mitgeben.

Hierdurch umgehen wir zum größten Teil diese Problematik, können Sie aber auch nicht ganz verhindern.

Nachtrag:
Was allerdings auch noch sein könnte, fährst Du einen Dispatcher Module Server für catiatojt + fmstranser +...?

Dann könntest Du evtl. in die MaximumTask Begrenzung des Moduls laufen (Default=3 Konverter-Tasks gleichzeitig).

Beispiel: Modul Task = 3 (transmodule.properties), CatiaToJT Maxlimit=3 (translator.xml), fmstransfer (1 task).

3 Konvertierungsprozesse für Catia --> fmstransfer steht solange an bis das Module wieder einen Task frei hat.

Gruß
Roland

[Diese Nachricht wurde von rosomapa am 21. Nov. 2012 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Roland,

Dein Tipp hat mir sehr weitergeholfen, danke.
Die Translators (catiatojt und fmstranfer) laufen bei uns auf einem Dispatcher Module Server.
Habe die MaximumTasks im transmodule.properties jetzt auf 4 gestellt, CatiaToJT Maxlimit=3,
somit bleibt immer ein Task für den fmstransfer frei und wird dann gleich übersetzt.

Was ich noch herausgefunden habe:
Wenn man die Preference TC_Store_and_Forward_transfer_delay=0 setzt, dann ist die Priority Low.
TC_Store_and_Forward_transfer_delay=1, dann ist die Priority None

Danke noch einmal für deine Hilfe.

------------------
MfG Michael

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP