---------------------------------------------------- * 2 oz (50ml) white rum Place the ice into a highball glass. * 1 lime Pour over the rum. Some more rum. * Cola Cut the lime in quarters. Squeeze * Ice one lime in (optional). Drop all the limes in. Top it up with Cola. -------------------------------------------------------------
Friday, July 10, 2015
Cuba Libre
Here is another break from all the typing.
žymės:
Cocktail
More Java grants on Oracle. ORA-29532 java.io.FilePermission
Abstract
I got a simple file system writer/reader, it starts with Oracle Directory alias and continues generating folders using organization number and some bits of date. Alias part is static, the rest.. ..is suppose to be generated infinitely. Not including mount, ownership and permission details, basically your main folder and subfolders have to be fully available to user running Oracle.
Short spec
Oracle Directory: /attachments/ (alias ATTACHMENTS)
Organization id: 301
Todays date monthly token: 0715
Schema in use: AWS
Error
Lets start with stack trace:
Possible fixes
Thing is you need write permissions in your Oracle dir, but in this case its recursive and never ending. I start with this:
BEGIN
dbms_java.grant_permission( 'AWS', 'SYS:java.io.FilePermission', '/attachments/*', 'write' );
END;
Small bit that made me spend couple of hours was recursive Java grant, just use dash "-" instead of "*" and grant will be valid for all your subdirectories:
BEGIN
dbms_java.grant_permission( 'AWS', 'SYS:java.io.FilePermission', '/attachments/-', 'write' );
END;
Just in case you need more then write - use full fleet of file permission types:
BEGIN
dbms_java.grant_permission( 'AWS', 'SYS:java.io.FilePermission', '/attachments/-', 'read,write,delete' );
END;
I got a simple file system writer/reader, it starts with Oracle Directory alias and continues generating folders using organization number and some bits of date. Alias part is static, the rest.. ..is suppose to be generated infinitely. Not including mount, ownership and permission details, basically your main folder and subfolders have to be fully available to user running Oracle.
Short spec
Oracle Directory: /attachments/ (alias ATTACHMENTS)
Organization id: 301
Todays date monthly token: 0715
Schema in use: AWS
Error
Lets start with stack trace:
<...>
java.security.AccessControlException: the Permission (java.io.FilePermission /attachments/301/0715/19871_head.txt write) has not been granted to AWS. The PL/SQL to grant this is dbms_java.grant_permission( 'AWS', 'SYS:java.io.FilePermission', '/attachments/301/0715/19871_head.txt', 'write' )
<...>
oracle.jdbc.driver.OracleSQLException: ORA-29532: Java call terminated by uncaught Java exception: java.security.AccessControlException: the Permission (java.io.FilePermission /attachments/301/0715/19871_head.txt write) has not been granted to AWS. The PL/S
QL to grant this is dbms_java.grant_permission( 'AWS', 'SYS:java.io.FilePermission', '/attachments/301/0715/19871_head.txt', 'write' )
<...>
Possible fixes
Thing is you need write permissions in your Oracle dir, but in this case its recursive and never ending. I start with this:
BEGIN
dbms_java.grant_permission( 'AWS', 'SYS:java.io.FilePermission', '/attachments/*', 'write' );
END;
Small bit that made me spend couple of hours was recursive Java grant, just use dash "-" instead of "*" and grant will be valid for all your subdirectories:
BEGIN
dbms_java.grant_permission( 'AWS', 'SYS:java.io.FilePermission', '/attachments/-', 'write' );
END;
Just in case you need more then write - use full fleet of file permission types:
BEGIN
dbms_java.grant_permission( 'AWS', 'SYS:java.io.FilePermission', '/attachments/-', 'read,write,delete' );
END;
Thursday, July 2, 2015
Leap second bug 2015. Linux/Centos, 100% CPU: Java, Oracle, OPMN, Tomcat
Oh dear, looks like there are services having serious issues with the Leap Second added last night. Read more about Leap Second 2015 in Wiki. Fix is simple:
# service ntpd stop; date -s "`date`";service ntpd start;
or
# /etc/init.d/ntpd stop; date -s "`date`"; /etc/init.d/ntpd start;
The problem occurred on an older Java/Oracle running webserver. All CPU's went 100% high. All services that had anything to do with JVM have gone bonkers: Tomcat, OPMN, Oracle, WebCache.
At first I disabled services that where failing and where not so important, but then all the others jumped to 100% CPU. It took some minutes before the situation was clear - all stuck services had one thing in common - JAVA. Once they went down, CPU went to idle. Ones who where prepared for this day did that 3 years ago. Happy restarting all the lazy admins.
žymės:
Java,
leap second,
OPMN,
Oracle,
Tomcat
Subscribe to:
Posts (Atom)