While checking server logs ERROR for ROCFM , facing disconnection in the ZOOKEEPER Connectivity - apache-zookeeper

In the server logs, noticing that there is a disconnection in the zookeeper connection.
Details of the log is below :-
[ INFO] [Mon Apr 04 11:02:58 2022] [Server:sbin/recordprocessor] [zookeeperutil.cc] [10.101.103.9] [183325] [recordprocessor] [] [2483025664] [(ChildrenNodeCheckWatcher) Extra zookeeper event occur in ChildrenNodeCheckWatcher, with zookeeper type and state on path -1 3 ]
[ ERROR] [Mon Apr 04 11:02:58 2022] [Server:sbin/recordprocessor] [zookeeperutil.cc] [10.101.103.9] [183325] [recordprocessor] [] [2483025664] [(ChildrenNodeCheckWatcher) zookeeperutil.cc:85 - Failed to get correct Event Type) - Event Type - ZOO_CHILD_EVENT]
[ INFO] [Mon Apr 04 11:02:58 2022] [Server:sbin/recordprocessor] [zookeeperutil.cc] [10.101.103.9] [183325] [recordprocessor] [] [2483025664] [(ChildrenNodeCheckWatcher) Extra zookeeper event occur in ChildrenNodeCheckWatcher, with zookeeper type and state on path -1 3 ]
[ ERROR] [Mon Apr 04 11:02:58 2022] [Server:sbin/recordprocessor] [zookeeperutil.cc] [10.101.103.9] [183325] [recordprocessor] [] [2483025664] [(ChildrenNodeCheckWatcher) zookeeperutil.cc:85 - Failed to get correct Event Type) - Event Type - ZOO_CHILD_EVENT]
[ INFO] [Mon Apr 04 11:02:58 2022] [Server:sbin/recordprocessor] [zookeeperutil.cc] [10.101.103.9] [183325] [recordprocessor] [] [2483025664] [(ExistsCheckWatcher) Extra zookeeper event occure in ExistsCheckWatcher with zookeeper type and state on path -1 3 ]
[ ERROR] [Mon Apr 04 11:02:58 2022] [Server:sbin/recordprocessor] [zookeeperutil.cc] [10.101.103.9] [183325] [recordprocessor] [] [2483025664] [(ExistsCheckWatcher) zookeeperutil.cc:156 - Failed to get correct Event Type) - Expected Event Type - ZOO_CREATED_EVENT]
[ INFO] [Mon Apr 04 11:02:58 2022] [Server:sbin/recordprocessor] [programmanagerutil.cc] [10.101.103.9] [183325] [recordprocessor] [] [2483025664] [(reInitializewatcher) Zookeeper connection got the ZOO_CONNECTED_STATE .........]

Related

Single planning calendar with fullday off

I have a problem with Single planning calendar.
I set fullday to false and set a startHour (8h) and endHour (17h).
But when i want to resize an appointment the startDate is not correct.
handleAppointmentResize: function (oEvent) {
var oAppointment = oEvent.getParameter("appointment"),
oStartDate = oEvent.getParameter("startDate"),
oEndDate = oEvent.getParameter("endDate"),
sAppointmentTitle = oAppointment.getTitle();
console.log(oStartDate);
console.log(oEndDate);
For exemple :
I have an appointment :
Wed Apr 06 2022 09:00:00 to Wed Apr 06 2022 13:00:00
I reduce them to 09:00 - 10:00
The result is
Mon Apr 04 2022 19:30:00 GMT+0200 (heure d’été d’Europe centrale)
Wed Apr 06 2022 09:00:00 GMT+0200 (heure d’été d’Europe centrale)
If i switch fullday to true, the result is ok !
Thanks for help
Resolve with upgrade of Sapui5 version

K8s cluster is healthy, but kubelet display unusual message repeatedly every minute

My k8s-env1 is on-premise and running well. I can create/get/describe/delete any k8s object.
However, I found kubelet display following message every minute, but it does not present in my another k8s-env2. Is this message ok on k8s-env1?
Feb 10 10:39:09 k8s-env1 kubelet[15461]: I0210 10:39:09.808611 15461 kubelet_getters.go:172] status for pod kube-controller-manager-k8s-env1 updated to {Running [{Initialized True 0001-01-01 00:00:00 +0000 UTC 2022-02-10 09:32:58 +0800 CST } {Ready True 0001-01-01 00:00:00 +0000 UTC 2022-02-10 09:32:58 +0800 CST } {ContainersReady True 0001-01-01 00:00:00 +0000 UTC 2022-02-10 09:32:58 +0800 CST } {PodScheduled True 0001-01-01 00:00:00 +0000 UTC 2022-02-10 09:32:58 +0800 CST }] 192.168.1.2 192.168.1.2 [{192.168.1.2}] 2022-02-10 09:32:58 +0800 CST [] [{kube-controller-manager {nil &ContainerStateRunning{StartedAt:2022-02-10 09:40:36 +0800 CST,} nil} {nil nil &ContainerStateTerminated{ExitCode:2,Signal:0,Reason:Error,Message:,StartedAt:2022-02-10 09:23:08 +0800 CST,FinishedAt:2022-02-10 09:38:13 +0800 CST,ContainerID:docker://1cc6e402be458374d365b6e379e7205267279c4da554c2207baca11cc1609be9,}} true 202 k8s.gcr.io/kube-controller-manager:v1.16.15 docker-pullable://k8s.gcr.io/kube-controller-manager#sha256:da7ac5487dc7b6eddfb4fbdf39af92bc065416a7dac147a937a39aff72716fe9 docker://7d0aa1e7ae3e3463347d68c644f45f97933ca819a4231b79a7fedcb5f8792dc6 0xc00189beb6}] Burstable []}
Feb 10 10:39:09 k8s-env1 kubelet[15461]: I0210 10:39:09.808770 15461 kubelet_getters.go:172] status for pod kube-scheduler-k8s-env1 updated to {Running [{Initialized True 0001-01-01 00:00:00 +0000 UTC 2022-02-10 09:32:58 +0800 CST } {Ready True 0001-01-01 00:00:00 +0000 UTC 2022-02-10 09:32:58 +0800 CST } {ContainersReady True 0001-01-01 00:00:00 +0000 UTC 2022-02-10 09:32:58 +0800 CST } {PodScheduled True 0001-01-01 00:00:00 +0000 UTC 2022-02-10 09:32:58 +0800 CST }] 192.168.1.2 192.168.1.2 [{192.168.1.2}] 2022-02-10 09:32:58 +0800 CST [] [{kube-scheduler {nil &ContainerStateRunning{StartedAt:2022-02-10 09:40:40 +0800 CST,} nil} {nil nil &ContainerStateTerminated{ExitCode:2,Signal:0,Reason:Error,Message:,StartedAt:2022-02-10 09:23:06 +0800 CST,FinishedAt:2022-02-10 09:38:14 +0800 CST,ContainerID:docker://94860e938310683e1a478d681256e649c00ba74570e70963b76804f60480b7a0,}} true 201 k8s.gcr.io/kube-scheduler:v1.16.15 docker-pullable://k8s.gcr.io/kube-scheduler#sha256:d9156baf649cd356bad6be119a62cf137b73956957604275ab8e3008bee96c8f docker://d626ea52253994ca2ee7d5b61ead84dacb0b99fd8f21b21268d92d53451e09af 0xc001c91189}] Burstable []}
Feb 10 10:39:09 k8s-env1 kubelet[15461]: I0210 10:39:09.808814 15461 kubelet_getters.go:172] status for pod kube-apiserver-k8s-env1 updated to {Running [{Initialized True 0001-01-01 00:00:00 +0000 UTC 2022-01-17 00:27:28 +0800 CST } {Ready True 0001-01-01 00:00:00 +0000 UTC 2022-01-28 13:17:18 +0800 CST } {ContainersReady True 0001-01-01 00:00:00 +0000 UTC 2022-01-17 00:38:58 +0800 CST } {PodScheduled True 0001-01-01 00:00:00 +0000 UTC 2022-01-17 00:27:28 +0800 CST }] 192.168.1.2 192.168.1.2 [{192.168.1.2}] 2022-01-17 00:27:28 +0800 CST [] [{kube-apiserver {nil &ContainerStateRunning{StartedAt:2022-02-10 09:40:33 +0800 CST,} nil} {nil nil &ContainerStateTerminated{ExitCode:137,Signal:0,Reason:Error,Message:,StartedAt:2022-02-10 09:23:05 +0800 CST,FinishedAt:2022-02-10 09:38:24 +0800 CST,ContainerID:docker://fcc0d48a9398656adc3e071b37f0f502ab45f0730e0d9ad51401db2b856fe1f3,}} true 16 k8s.gcr.io/kube-apiserver:v1.16.15 docker-pullable://k8s.gcr.io/kube-apiserver#sha256:58075c15f5978b4b73e58b004bb3a1856ad58a9061ac3075ef860207ba00ac75 docker://95a526b063d00b5eb497dc3280a0cf4610fec31a072685eb7279f5207dcc27b1 0xc00156e74c}] Burstable []}
Feb 10 10:39:10 k8s-env1 kubelet[15461]: I0210 10:39:10.064116 15461 kubelet_network_linux.go:141] Not using `--random-fully` in the MASQUERADE rule for iptables because the local version of iptables does not support it
In theory this shouldn't affect any functionality, but to.get rid of this you can try installing a iptables version(1.6.2) which has support to the random fully. Something like this should do
Run the following inside the kubelet and reboot once done
apt remove --purge iptables && \
apt autoremove -y && \
clean-install libip4tc0=1.6.2-1.1~bpo9+1 \
libip6tc0=1.6.2-1.1~bpo9+1 \
libiptc0=1.6.2-1.1~bpo9+1 \
libxtables12=1.6.2-1.1~bpo9+1 \
iptables=1.6.2-1.1~bpo9+1

Order of objects retrieved from working memory in Drools

We have been coding a rule that changes the status of billed items that are repeated on the same day and that should only be billed once a day. All items have a status of 2 or 3 to begin with.
If a duplicated code is detected on an item with status 2 or 3, the item will get status 4 and the item in the working memory is updated.
When realising unit testing we can see the results are correct, but once we retrieve the objects from the working memory it seems the order of the items has changed to pretty much random.
Is this normal and why does it happen? (Obviously, the anomaly, if any, could be corrected by just reordering the list again).
Objects are inserted this way:
Iterator<Object> it = objects.iterator();
while (it.hasNext()) {
sessionStatefull.insert(it.next());
}
Its log is achieved by adding a logger to the KieSession:
public static KieSession getStatefulKnowledgeSessionWithCallback(KieContainer kieContainer, String sessionName) {
KieSession kieSession = null;
try {
kieSession = getStatefulKnowledgeSession(kieContainer, sessionName);
kieSession.addEventListener(new RuleRuntimeEventListener() {
OutputDisplay outputDisplay = new OutputDisplay();
#Override
public void objectInserted(ObjectInsertedEvent objectInsertedEvent) {
outputDisplay.showText("getStatefulKnowledgeSessionWithCallback.INSERT", objectInsertedEvent.getObject().toString());
}
The input is always the same:
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=2, id=150107315169800, units=1.0, code=1 ]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=2, id=150107315169801, units=1.0, code=1 ]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=2, id=150107315169802, units=1.0, code=2 ]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=2, id=150107315169803, units=1.0, code=2 ]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=2, id=150107315169804, units=1.0, code=6358]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=2, id=150107315169805, units=1.0, code=6007]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=2, id=150107315169806, units=1.0, code=6007]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=2, id=150107315169807, units=1.0, code=6385]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=2, id=150107315169808, units=1.0, code=6005]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=2, id=150107315169809, units=1.0, code=6225]
The output is obtained this way:
List<Object> list = new ArrayList<Object>((Collection<Object>) sessionStatefull.getObjects());
Its log is obtained with an Iterator:
Iterator<Object> it2 = list.iterator();
while (it2.hasNext()) {
Object object = it2.next();
outputDisplay.showText("Result: ", object.toString());
}
The printed output always seems to have a random order:
Example 1:
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=2, id=150107315169809, units=1.0, code=6225]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=4, id=150107315169801, units=1.0, code=1 ]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=2, id=150107315169800, units=1.0, code=1 ]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=4, id=150107315169803, units=1.0, code=2 ]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=2, id=150107315169802, units=1.0, code=2 ]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=2, id=150107315169807, units=1.0, code=6385]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=2, id=150107315169805, units=1.0, code=6007]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=2, id=150107315169804, units=1.0, code=6358]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=4, id=150107315169806, units=1.0, code=6007]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=2, id=150107315169808, units=1.0, code=6005]
Example 2:
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=2, id=150107315169804, units=1.0, code=6358]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=4, id=150107315169803, units=1.0, code=2 ]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=4, id=150107315169806, units=1.0, code=6007]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=2, id=150107315169805, units=1.0, code=6007]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=4, id=150107315169801, units=1.0, code=1 ]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=2, id=150107315169808, units=1.0, code=6005]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=2, id=150107315169807, units=1.0, code=6385]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=2, id=150107315169800, units=1.0, code=1 ]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=2, id=150107315169809, units=1.0, code=6225]
Item [date=Tue Jul 25 00:00:00 CEST 2017, status=2, id=150107315169802, units=1.0, code=2 ]
The logger class is defined like this:
public class OutputDisplay {
public void showText(String source, String text) {
try {
long time = System.currentTimeMillis();
Date date = new Date(time);
writeLog(time+" "+date.toString()+" A message from "+source+": "+text);
} catch (Exception exception) {
exception.printStackTrace();
}
}
writeLog opens a file and adds the line. We haven't paid any attention yet to some more sophisticated logging (i.e. logback...).
Drools doesn't internally keep the order of the inserted objects. The getObjects() method you are using states this by returning a Collection instead of a List.
The logger is showing the objects in order because it is invoked as soon as a new object is inserted into the working memory.
If you want to give some logical order to your objects I would suggest you to order them after you retrieve them from the working memory.
Hope it helps,

Maybe a bug in temporal reasoning on drools?

I want to test a scenario with temporal reasoning on drools. I have a Message class with timestamp field. when each event of this class received by drools, inserted into working memory and called fireAllRules(). in every firing I want to print timestamp of paired message ml and mo, that is ml after[0s,160s] mo. when I write my rule like below every things is Ok.
rule "Rule 1"
when
ml: Message()
mo: Message(ml after[0s,160s] this)
then
System.out.println("ml:"+new Date(ml.timestamp));
System.out.println("mo:"+new Date(mo.timestamp));
end
output:
Message received{"timestamp":"Feb 8 19:39:45", ... }
ml:Sun Feb 08 19:39:45 IRST 1970
mo:Sun Feb 08 19:39:45 IRST 1970
Message received{"timestamp":"Feb 8 19:40:04", ... }
ml:Sun Feb 08 19:40:04 IRST 1970
mo:Sun Feb 08 19:39:45 IRST 1970
ml:Sun Feb 08 19:40:04 IRST 1970
mo:Sun Feb 08 19:40:04 IRST 1970
Message received{"timestamp":"Feb 8 19:40:15", ... }
ml:Sun Feb 08 19:40:15 IRST 1970
mo:Sun Feb 08 19:40:04 IRST 1970
ml:Sun Feb 08 19:40:15 IRST 1970
mo:Sun Feb 08 19:39:45 IRST 1970
ml:Sun Feb 08 19:40:15 IRST 1970
mo:Sun Feb 08 19:40:15 IRST 1970
But when I rewrite rule in this form the output is not good.
rule "Rule 1"
when
ml: Message()
mo: Message(this before[0s,160s] ml)
then
System.out.println("ml:"+new Date(ml.timestamp));
System.out.println("mo:"+new Date(mo.timestamp));
end
output:
Message received{"timestamp":"Feb 8 19:41:40", ... }
ml:Sun Feb 08 19:41:40 IRST 1970
mo:Sun Feb 08 19:41:40 IRST 1970
Message received{"timestamp":"Feb 8 19:41:57", ... }
ml:Sun Feb 08 19:41:57 IRST 1970
mo:Sun Feb 08 19:41:57 IRST 1970
Message received{"timestamp":"Feb 8 19:42:02", ... }
ml:Sun Feb 08 19:42:02 IRST 1970
mo:Sun Feb 08 19:42:02 IRST 1970
Why in second form the output is not good? this problem observed when I used two parameters for temporal operators and "this" is the first operand.
Is "this before[0s,160s] ml" equals to "ml after[0s,160s] this"?
The second form is a bug?

SBT 0.12.1 downloads wrong SNAPSHOT

I deploy some SNAPSHOT dependencies to Sonatype OSS using mvn. Sonatype stores a number of old snapshots for each coordinate. A directory listing of my deployed SNAPSHOTs is at the bottom of this question.
In my sbt Play! project, I added the Sonatype SNAPSHOT repository as a resolver.
val main = PlayProject(appName, appVersion, appDependencies, mainLang = SCALA).settings(
// Add your own project settings here
resolvers += "Sonatype snapshots" at "http://oss.sonatype.org/content/repositories/snapshots/"
)
However, the wrong SNAPSHOT is downloaded each time. While sbt should download the last deployed SNAPSHOT (20130109.225335-6) but it downloads the first deployed SNAPSHOT (20130109.210948-1).
$ rm -r ~/.ivy2/cache/edu.washington.cs.knowitall.chunkedextractor/
$ sbt clean compile
[info] Loading project definition from /scratch/github/knowitall/documentextractor/project
[info] Set current project to documentextractor (in build file:/scratch/github/knowitall/documentextractor/)
[success] Total time: 0 s, completed Jan 9, 2013 3:06:41 PM
[info] Updating {file:/scratch/github/knowitall/documentextractor/}documentextractor...
[info] downloading http://repo.typesafe.com/typesafe/snapshots/edu/washington/cs/knowitall/chunkedextractor/chunkedextractor_2.9.2/1.0.1-SNAPSHOT/chunkedextractor_2.9.2-1.0.1-20130109.210948-1.jar ...
[info] [SUCCESSFUL ] edu.washington.cs.knowitall.chunkedextractor#chunkedextractor_2.9.2;1.0.1-SNAPSHOT!chunkedextractor_2.9.2.jar (1079ms)
[info] Done updating.
Any idea how I can fix this and make sbt download the most recent SNAPSHOT? Is this an sbt-specific problem or does it have to do with Play!?
Here is the directory listing of my artifact's snapshots on Sonatype.
https://oss.sonatype.org/content/repositories/snapshots/edu/washington/cs/knowitall/chunkedextractor/chunkedextractor_2.9.2/1.0.1-SNAPSHOT/
chunkedextractor_2.9.2-1.0.1-20130109.210948-1-javadoc.jar Wed Jan 09 15:09:55 CST 2013 361379
chunkedextractor_2.9.2-1.0.1-20130109.210948-1-javadoc.jar.md5 Wed Jan 09 15:09:56 CST 2013 32
chunkedextractor_2.9.2-1.0.1-20130109.210948-1-javadoc.jar.sha1 Wed Jan 09 15:09:56 CST 2013 40
chunkedextractor_2.9.2-1.0.1-20130109.210948-1-sources.jar Wed Jan 09 15:09:53 CST 2013 17175
chunkedextractor_2.9.2-1.0.1-20130109.210948-1-sources.jar.md5 Wed Jan 09 15:09:54 CST 2013 32
chunkedextractor_2.9.2-1.0.1-20130109.210948-1-sources.jar.sha1 Wed Jan 09 15:09:53 CST 2013 40
chunkedextractor_2.9.2-1.0.1-20130109.210948-1.jar Wed Jan 09 15:09:48 CST 2013 178994
chunkedextractor_2.9.2-1.0.1-20130109.210948-1.jar.md5 Wed Jan 09 15:09:49 CST 2013 32
chunkedextractor_2.9.2-1.0.1-20130109.210948-1.jar.sha1 Wed Jan 09 15:09:49 CST 2013 40
chunkedextractor_2.9.2-1.0.1-20130109.210948-1.pom Wed Jan 09 15:09:49 CST 2013 3725
chunkedextractor_2.9.2-1.0.1-20130109.210948-1.pom.md5 Wed Jan 09 15:09:50 CST 2013 32
chunkedextractor_2.9.2-1.0.1-20130109.210948-1.pom.sha1 Wed Jan 09 15:09:50 CST 2013 40
chunkedextractor_2.9.2-1.0.1-20130109.222121-2-javadoc.jar Wed Jan 09 16:21:29 CST 2013 363291
chunkedextractor_2.9.2-1.0.1-20130109.222121-2-javadoc.jar.md5 Wed Jan 09 16:21:30 CST 2013 32
chunkedextractor_2.9.2-1.0.1-20130109.222121-2-javadoc.jar.sha1 Wed Jan 09 16:21:30 CST 2013 40
chunkedextractor_2.9.2-1.0.1-20130109.222121-2-sources.jar Wed Jan 09 16:21:27 CST 2013 17195
chunkedextractor_2.9.2-1.0.1-20130109.222121-2-sources.jar.md5 Wed Jan 09 16:21:27 CST 2013 32
chunkedextractor_2.9.2-1.0.1-20130109.222121-2-sources.jar.sha1 Wed Jan 09 16:21:27 CST 2013 40
chunkedextractor_2.9.2-1.0.1-20130109.222121-2.jar Wed Jan 09 16:21:21 CST 2013 177267
chunkedextractor_2.9.2-1.0.1-20130109.222121-2.jar.md5 Wed Jan 09 16:21:22 CST 2013 32
chunkedextractor_2.9.2-1.0.1-20130109.222121-2.jar.sha1 Wed Jan 09 16:21:22 CST 2013 40
chunkedextractor_2.9.2-1.0.1-20130109.222121-2.pom Wed Jan 09 16:21:23 CST 2013 3725
chunkedextractor_2.9.2-1.0.1-20130109.222121-2.pom.md5 Wed Jan 09 16:21:23 CST 2013 32
chunkedextractor_2.9.2-1.0.1-20130109.222121-2.pom.sha1 Wed Jan 09 16:21:23 CST 2013 40
chunkedextractor_2.9.2-1.0.1-20130109.223017-3-javadoc.jar Wed Jan 09 16:30:25 CST 2013 363291
chunkedextractor_2.9.2-1.0.1-20130109.223017-3-javadoc.jar.md5 Wed Jan 09 16:30:26 CST 2013 32
chunkedextractor_2.9.2-1.0.1-20130109.223017-3-javadoc.jar.sha1 Wed Jan 09 16:30:25 CST 2013 40
chunkedextractor_2.9.2-1.0.1-20130109.223017-3-sources.jar Wed Jan 09 16:30:22 CST 2013 17195
chunkedextractor_2.9.2-1.0.1-20130109.223017-3-sources.jar.md5 Wed Jan 09 16:30:23 CST 2013 32
chunkedextractor_2.9.2-1.0.1-20130109.223017-3-sources.jar.sha1 Wed Jan 09 16:30:23 CST 2013 40
chunkedextractor_2.9.2-1.0.1-20130109.223017-3.jar Wed Jan 09 16:30:18 CST 2013 177267
chunkedextractor_2.9.2-1.0.1-20130109.223017-3.jar.md5 Wed Jan 09 16:30:18 CST 2013 32
chunkedextractor_2.9.2-1.0.1-20130109.223017-3.jar.sha1 Wed Jan 09 16:30:18 CST 2013 40
chunkedextractor_2.9.2-1.0.1-20130109.223017-3.pom Wed Jan 09 16:30:19 CST 2013 3725
chunkedextractor_2.9.2-1.0.1-20130109.223017-3.pom.md5 Wed Jan 09 16:30:19 CST 2013 32
chunkedextractor_2.9.2-1.0.1-20130109.223017-3.pom.sha1 Wed Jan 09 16:30:19 CST 2013 40
chunkedextractor_2.9.2-1.0.1-20130109.224717-4-javadoc.jar Wed Jan 09 16:47:24 CST 2013 363343
chunkedextractor_2.9.2-1.0.1-20130109.224717-4-javadoc.jar.md5 Wed Jan 09 16:47:24 CST 2013 32
chunkedextractor_2.9.2-1.0.1-20130109.224717-4-javadoc.jar.sha1 Wed Jan 09 16:47:24 CST 2013 40
chunkedextractor_2.9.2-1.0.1-20130109.224717-4-sources.jar Wed Jan 09 16:47:21 CST 2013 17198
chunkedextractor_2.9.2-1.0.1-20130109.224717-4-sources.jar.md5 Wed Jan 09 16:47:22 CST 2013 32
chunkedextractor_2.9.2-1.0.1-20130109.224717-4-sources.jar.sha1 Wed Jan 09 16:47:22 CST 2013 40
chunkedextractor_2.9.2-1.0.1-20130109.224717-4.jar Wed Jan 09 16:47:17 CST 2013 177369
chunkedextractor_2.9.2-1.0.1-20130109.224717-4.jar.md5 Wed Jan 09 16:47:18 CST 2013 32
chunkedextractor_2.9.2-1.0.1-20130109.224717-4.jar.sha1 Wed Jan 09 16:47:17 CST 2013 40
chunkedextractor_2.9.2-1.0.1-20130109.224717-4.pom Wed Jan 09 16:47:18 CST 2013 3725
chunkedextractor_2.9.2-1.0.1-20130109.224717-4.pom.md5 Wed Jan 09 16:47:19 CST 2013 32
chunkedextractor_2.9.2-1.0.1-20130109.224717-4.pom.sha1 Wed Jan 09 16:47:18 CST 2013 40
chunkedextractor_2.9.2-1.0.1-20130109.225244-5-javadoc.jar Wed Jan 09 16:52:52 CST 2013 363343
chunkedextractor_2.9.2-1.0.1-20130109.225244-5-javadoc.jar.md5 Wed Jan 09 16:52:52 CST 2013 32
chunkedextractor_2.9.2-1.0.1-20130109.225244-5-javadoc.jar.sha1 Wed Jan 09 16:52:52 CST 2013 40
chunkedextractor_2.9.2-1.0.1-20130109.225244-5-sources.jar Wed Jan 09 16:52:49 CST 2013 17198
chunkedextractor_2.9.2-1.0.1-20130109.225244-5-sources.jar.md5 Wed Jan 09 16:52:50 CST 2013 32
chunkedextractor_2.9.2-1.0.1-20130109.225244-5-sources.jar.sha1 Wed Jan 09 16:52:50 CST 2013 40
chunkedextractor_2.9.2-1.0.1-20130109.225244-5.jar Wed Jan 09 16:52:45 CST 2013 177369
chunkedextractor_2.9.2-1.0.1-20130109.225244-5.jar.md5 Wed Jan 09 16:52:46 CST 2013 32
chunkedextractor_2.9.2-1.0.1-20130109.225244-5.jar.sha1 Wed Jan 09 16:52:45 CST 2013 40
chunkedextractor_2.9.2-1.0.1-20130109.225244-5.pom Wed Jan 09 16:52:46 CST 2013 3725
chunkedextractor_2.9.2-1.0.1-20130109.225244-5.pom.md5 Wed Jan 09 16:52:47 CST 2013 32
chunkedextractor_2.9.2-1.0.1-20130109.225244-5.pom.sha1 Wed Jan 09 16:52:46 CST 2013 40
chunkedextractor_2.9.2-1.0.1-20130109.225335-6-javadoc.jar Wed Jan 09 16:53:42 CST 2013 363343
chunkedextractor_2.9.2-1.0.1-20130109.225335-6-javadoc.jar.md5 Wed Jan 09 16:53:43 CST 2013 32
chunkedextractor_2.9.2-1.0.1-20130109.225335-6-javadoc.jar.sha1 Wed Jan 09 16:53:42 CST 2013 40
chunkedextractor_2.9.2-1.0.1-20130109.225335-6-sources.jar Wed Jan 09 16:53:40 CST 2013 17198
chunkedextractor_2.9.2-1.0.1-20130109.225335-6-sources.jar.md5 Wed Jan 09 16:53:40 CST 2013 32
chunkedextractor_2.9.2-1.0.1-20130109.225335-6-sources.jar.sha1 Wed Jan 09 16:53:40 CST 2013 40
chunkedextractor_2.9.2-1.0.1-20130109.225335-6.jar Wed Jan 09 16:53:35 CST 2013 177369
chunkedextractor_2.9.2-1.0.1-20130109.225335-6.jar.md5 Wed Jan 09 16:53:36 CST 2013 32
chunkedextractor_2.9.2-1.0.1-20130109.225335-6.jar.sha1 Wed Jan 09 16:53:36 CST 2013 40
chunkedextractor_2.9.2-1.0.1-20130109.225335-6.pom Wed Jan 09 16:53:36 CST 2013 3725
chunkedextractor_2.9.2-1.0.1-20130109.225335-6.pom.md5 Wed Jan 09 16:53:37 CST 2013 32
chunkedextractor_2.9.2-1.0.1-20130109.225335-6.pom.sha1 Wed Jan 09 16:53:37 CST 2013 40
maven-metadata.xml Wed Jan 09 16:53:43 CST 2013 1244
maven-metadata.xml.md5 Wed Jan 09 16:53:44 CST 2013 32
maven-metadata.xml.sha1 Wed Jan 09 16:53:43 CST 2013 40
UPDATE: build.properties specifies sbt.version=0.11.3. Maybe Play is forcing this older version of sbt.
Try if one of these might help you:
1) run 'update'
2) modify dependency to "groupId" %% "artifactId" % "version" changing() and run 'update'