Via core service you can retrieve PublishTransactionData object, which contains all info about transaction itself:
PublishTransactionData transaction = (PublishTransactionData)Client.Read(transactionID, new ReadOptions());
PublishTransactionState transactionState = transaction.State;
DateTime transactionStateChange = transaction.StateChangeDateTime;
For #1 publishing priority is the way to go. Maybe changing the default priority to "low" will give you enough of an override to push things through quickly. Using publishing priorities in conjunction with the information I share in the blog post on keeping threads available.
Item #2 might need event system, but you should be careful of performance impacts. ...
It's the same event as publishing 'now'.
The difference is simply that the PublishInstruction will have the StartAt property set to the date/time selected for rendering, and the DeployAt property set to the date/time selected for placing the content online.
In your cd_deployer_conf.xml, modify the "Cleanup" attribute of the Queue Location element to be "false":
<Location Path="c:\tridion\staging\incoming" WindowSize="20" Workers="10" Cleanup="false" Interval="2s"/>
Restart your deployer for these changes to take effect.
Modify your ...
The publishing queue will indeed only show the last transaction with a given state. If you have 10 failed publishing transactions, the queue will only show the last one, as we assume that the previous 9 are irrelevant to you.
As of 2013 SP1 Tridion actually keeps all the data - this was not the case before, in the database we would actually delete "...
What you are requiring is mainly to use publish queue in a way its not meant to be used.
For #1 you want to publish items before all others. That is the exact purpose of "high" priority. Problem is when editors abuse this priority so you have thousand of items in queue on high.
Using event system to remove/resend transactions can be very time and resource ...
The event you attached to is probably the "Submit item for publishing" event, which, as you figured out, ends once the page is sent to the publishing queue.
The event you want to listen to is on the PublishTransaction object, as mentioned in this response.
Basically, you should check whenever a PublishTransaction is updated for the transaction status. Once ...
The transport package format is undocumented, and not a valid extension point - therefore I doubt you'll find much information publicly.
However... it's really easy to figure this out, as all you need is a copy of a few Transport Packages and the ability to unzip files. You can easily configure your deployer to keep copies of the successful transport ...
Regarding the "Why are there two 'Rendering' states?", or more accurately "Why are there two Save events with State 'Rendering'?": you already more or less answered the question yourself -- the first one is for the State change to 'Rendering', the second one for changing the ProcessedItems.
IIRC, the ResolvedItems property is derived from ProcessedItems. I ...
To mimic the filtering capabilities of the Publishing queue, take a look at the PublishTransactionsFilterData and its properties.
Use the filter paired with GetSystemWideList or GetSystemWideListXml and you can obtain an array of PublishTransactionData or their Ids.
If you have a publish transaction id, you can read it by using the Read method and the ...
I don't believe this is possible. We had a similar case where we needed to increase the priority of some items in the queue.
I tried similar in 2011 but used Save and not Update. It threw a similar error message (can't remember, but it was most likely the same).
Since ours were occasional one off cases, we just ended up doing it via the GUI, but it looks ...
You could create a (dummy) Page based on a Page Template which collects and renders the required CT metadata of all CTs (in JSON or XML format).
Publishing the metadata of all CTs can be achieved by publishing that single (dummy) Page. Likewise, retrieving the metadata of all CTs can be achieved by requesting that single Page.
After doing some research, and with Eric Huiza's help, we realized it was a logging problem when using Log4Net in a Event System / Workflow Context.
so, The problem was that there was more than 1 process trying to write the logs. When the workflow started the publication procedure, it was the TcmServiceHost the one that acually started the publication (...
The StateChangeDate gets the date/time when the last state change occurred for the transaction. So it will tell you when the transactions current state is achieved. And if the transaction is published successfully (means its in published state (6)), the property will give you the time when the item is published.
@Chris-Summers - It is possible to retrieve package size in Transport package handler.
You can override method Send as given below
public void send(File transportFile) throws TransportException
//based on transportFile.length() you can throw exception.
Hope this helps.
In addition to Jonathan's response above that the impact of increasing threads depends on a number of factors...
You can note that a task that consumes lots of CPU power and does not require I/O (such as calculating PI or prime numbers) then 1 thread per CPU will probably be best.
Where a task is bound to I/O - such as processing information from disk, ...
As mentioned by Nuno's answer to Content Management System with a separate Publisher Server, more threads does not always better performance:
Finding the right balance between # of threads and performance is an
art, with a lot of variables that may impact it - database
performance, template optimization, network bandwidth between
transport & ...
The easiest way to do this is to create a module, deriving from com.tridion.deployer.Module. This module can then be placed in a separate Processor node in your cd_deployer_conf.xml, where you can add a phase to the configuration element, which in your case would then be: post-transaction.
In total it would look like this:
<Processor Action="Deploy" ...
After sharing a tip to publish from parent publications (that I learned from Kelly Thompson), Bart Koopman and Will Price added two parts to the publish-from-parent scenario:
You already did the custom resolver part to remove the queue parent items (as Bart suggested).
See Will Price's additional step to remove the empty Publish transactions:
To my knowledge data is stored in the commitTransaction operation in the storage layer so extending this by calling the base operation and after that making your query to the webserver should yield the desired results.
For this to work you would have to create a storage extension (not a deployer extension!); i believe Will explains how the factory commits ...
I am not quite in agreement with your findings. In addition to what Nuno has said, the Deployer Extension in the Post-Transaction will get executed after the Publishing Transaction is committed. You may want to check the methodology that you are using to retrieve the content if you are receiving an older version of it. Further since you are using SDL Tridion ...
This is a very broad question, that cannot really be answered without knowing what your templates are doing.
There's a few things to look at. You report stability issues, which would suggest you have code quality issues. Perhaps bad memory management, usage of COM objects in templates that are not correctly released from memory, etc.
You also should look ...
The PublishContexts property is null because you are requesting a list of PublishTransactions and, in general, for lists only a subset of the properties are loaded.
If you read an individual PublishTransaction, the property will have a value.
Deleting is always an issue with code in SDL Tridion. There could be many possibilities in which case your code will fail:
(As somewhat suggested by Hiren) You call the unpublish method and the choose to un-publish it from all the Publication targets and you call the delete before it actually got publish from all the Publishing targets and you can never ...
There are three ways of possibly doing this off the top of my head:
As Nickoli says, you could write a Custom GUI Extension for the CME interface.
You could script this using a Bookmarklet - This would also allow you to enter the Tridion bookmarklet challenge!
You could write your own Custom Page, using the Core Service, that watches the publishing queue ...
The short answer is "Something is wrong with your implementation or installation. You should not need to restart all these service and pages should take fractions of seconds to publish - not minutes."
As suggested by @Rai, you should look for some logs and errors to diagnose the issue. Restarting the services is really a "band-aid", and is not addressing ...
If you don't want to use a Custom Transport Handler, another way to handle that could be using the Event System.
You create in a folder one component per category (Use a specific schema, as the purpose of this is just create a mapping).
When you publish a category, using event system you publish the component that maps the category.
Doing this, you end up ...
I think that in this scenario the only option is a Custom Transport Handler. You can see details in my answer here Custom Transport Handler
In your case you will need to replace this Handler
You can probably use the StateChangeDate. This is the time publish transaction state was changed for the last time. It basically shows you, for how long is you publish transaction in rendering or waiting. Just be careful with scheduled transactions.